AD-A185  493 


AFIT/GST/ENS/87J 


OIK  FILE 


APPLICATION  OF  ARTIFICIAL  INTELLIGENCE 

IN  A  CONFLICT  ANALYSIS  DECISION  AID 

THESIS 

Rollin  J  Lutz,  Jr. 

Major,  USAF 

AFrr/GST/ENS/87J-  /  0 


Approved  for  public  release;  distribution  unlimited 


AFTT/GST/ENS/87J 


APPLICATION  OF  ARTIFICIAL  INTELLIGENCE 
IN  A  CONFLICT  ANALYSIS  DECISION  AID 


THESIS 


Presented  to  the  Faculty  of  the  School  of  Engineering 
of  the  Air  Force  Institute  of  Technology 
Air  University 
In  Partial  Fulfillment  of  the 


Requirements  for  the  Degree  of 
Master  of  Science  in  Operations  Research 


Rollin  J.  Lutz,  B.S. 
Major,  USAF 

June  1987 


Approved  for  public  release;  distribution  unlimited 


Preface 


The  purpose  of  this  research  was  to  demonstrate  the  feasibility  of  blending 
operations  research  and  artificial  intelligence  techniques.  A  unique  prototype 
system  was  developed.  The  prototype,  an  expert  system,  was  developed  and  totally 
integrated,  under  the  control  of  a  C  language  program. 

The  success  of  this  research  would  not  have  been  possible  without  the  great 
support  provided  to  me  by  many  individuals.  To  those  dedicated  people,  I  am 
deeply  indebted.  I  thank  my  advisors,  Lt.Col.  Parnell  and  Colonel  O’Connell  for 
their  professional  guidance  throughout  this  work.  I  also  wish  to  thank  Mr.  Robert 
Carrol  and  the  staff  at  Software  A&E  for  their  support  in  answering  my  many 
questions.  Without  the  special  version  of  KES,  which  they  so  graciously  provided, 
this  effort  would  not  have  possible.  I  wish  to  express  my  appreciation  to  the 
Operational  Sciences  Department  of  the  Air  Force  Institute  of  Technology  for 
providing  the  resources  which  made  this  effort  possible.  In  particular  though,  I  wish 
to  thank  my  wife,  Shelley  and  daughter,  Marjorie  for  their  love,  patience  and 
understanding.  They  dragged  me  back  to  sanity  from  the  perpetual  late  hours  at  the 
computer,  in  which  I  was  forever  engulfed. 
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Abstract 


This  report  documents  the  research  conducted  to  develop  a  decision  aid  for 
an  operations  research  methodology,  conflict  analysis.  The  purpose  of  this  research 
was  to  demonstrate  the  feasibility  of  blending  artificial  intelligence  and  operations 
research  techniques.  A  prototype  system  was  designed,  developed,  and 
implemented  in  the  form  of  an  expert  system.  Unique  in  this  design,  was  the  expert 
system  embedded  completely  within  a  conventional  C  language  program.  The 
prototype  automated  many  of  the  tedious  calculations  and  processes  performed  in  a 
classic  conflict  analysis. 

The  development  process  was  conducted  in  three  phases.  First,  the  system 
requirements  were  established.  Second,  design  tradeoffs  were  made  in  the  choice  of 
tools  and  software.  Third,  the  prototype  was  built  using  two  parallel  development 
tracks.  Separate  design  components  were  completed  in  the  conventional  C 
language  program  and  in  the  expert  system  program.  When  fully  tested  and 
debugged,  the  two  programs  were  integrated  within  the  C  language  program. 
Proper  system  performance  was  evaluated  by  comparison  of  results  using  a  varied 
selection  of  classic  problems.  Finally,  the  results  of  the  research  are  presented  with 
recommendations  for  future  work.  (  U  j  /h  '■oLo'ft 
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APPLICATION  OF  ARTIFICIAL  INTELLIGENCE 
IN  A  CONFLICT  ANALYSIS  DECISION  AID 


I.  Introduction 


Artificial  Intelligence  has  made  significant  inroads  in  military  and 
commercial  decision  aids.  Research  in  this  field  is  growing  rapidly  as  new  and 
improved  tools  are  applied  to  difficult  problems.  This  research  focuses  on  the 
design  of  a  computer  decision  aid  by  applying  expert  system  tools  to  the  military 
intelligence  analysis  of  conflict  situations. 

Topic  Statement 

This  report  covers  the  research  and  development  of  an  expert  system  which 
can  aid  a  militaiy  analyst.  The  purpose  of  this  effort  was  not  to  replace  the  expert, 
rather  to  give  the  analyst  a  tool.  Using  such  a  tool,  the  process  is  accelerated  and 
the  analyst  has  time  to  view  the  larger  picture  without  being  mired  in  the  details. 
Although  not  the  primary  objective,  this  effort  should  produce  a  system  friendlier  to 
the  user. 

Overview  of  Military  Intelligence  in  Combat  Operations 

Warfare  is  both  a  science  and  an  art  as  old  as  the  earliest  history  of  mankind. 
Approximately  2500  years  ago  Sun  Tzu  noted,  "The  art  of  war  is  of  vital  importance 


to  the  state.  It  is  a  matter  of  life  and  death,  a  road  either  to  safety  or  to  ruin. 
Hence,  under  no  circumstances  can  it  be  neglected."[14]  Sun  Tzu’s  conclusions  are 
still  applicable  to  conflicts  in  the  world  today  in  spite  of  all  the  technology  changes. 

The  technology  of  Chinese  weapons  in  500  B.C.  was  admittedly  crude  by 
modem  standards.  Bows  and  arrows  soon  gave  way  to  gun  powder,  but  armies  still 
marched  over  the  continent  at  the  same  speed.  Gun  and  artillery  batteries 
projected  their  force  in  ever  increasing  distances  as  technology  improved.  Once  the 
armored  tank  appeared  in  World  War  I,  however,  the  speed  of  battle  was  forever 
altered.  Aircraft  soon  appeared,  projecting  power  greater  distance  and  more 
rapidly  than  ever  before.  The  effect  of  these  advances  in  weaponry  was  greater 
destructive  power  delivered  in  decreasing  amounts  of  time.  The  military 
commander,  however,  has  changed  very  little  throughout  history.  He  must  still 
assess,  decide,  and  act  in  much  the  same  manner  as  Sim  Tzu  only  he  must  do  it  in 
less  time. 


Prior  to  World  War  II,  the  effectiveness  of  a  commander 
depended  almost  entirely  upon  his  ability  to  remember  and  to  act 
upon  the  tenets  of  what  might  well  be  termed  a  Commander’s 
Catechism.  ’Hie  pace  of  war  until  that  time  was  such  that  a 
commander,  aided  by  his  staff  could  gather  the  necessary  information, 
weigh  each  factor  carefully,  generate  and  evaluate  reasonable 
hypotheses,  and  identify  appropriate  option  alternatives  for  command 
decisions.  The  speed  of  numan  thought  and  even  of  organizational 
interaction,  bureaucratic  as  it  may  nave  been,  was  more  or  less 
adequate  to  the  task;  and  from  a  communications  standpoint  the 
"runner"  had  already  been  replaced  by  the  motorcycle  rider  and  by  the 
wire  line  communications.[ly:619] 


World  War  II  produced  many  advances  such  as  the  jet  aircraft,  the  German 
Blitzkrieg,  and  radio  communications.  The  increased  speed  of  operations  stretched 
the  capabilities  of  military  organizations  to  react.  Organizational  changes  were 


made  to  streamline  the  decision  making  "roces. .  Th-  of  fighting  inside  the 
enemy  ttdedsion  cycle"  began  to  emerge. 

The  concept  that  the  commander  must  assess,  plan,  and  act  within  ever 
shortening  periods  of  time  is  important  to  current  operations.  Shortening  the 
decision  cycle  does  not  mean  a  less  thorough  assessment,  plan,  or  action  is 
acceptable.  Returning  to  Sun  Tzu’s  advice  on  planning: 

The  general  who  wins  a  battle  makes  many  calculations  in  his  temple 
before  die  battle  is  fought.  The  general  who  loses  a  battle  makes  but 
a  few  calculations  beforehand.  Thus  do  many  calculations  lead  to 
victory,  and  few  calculations  to  defeat;  how  much  more  no  calculation 
at  all!  It  is  by  attention  to  this  point  that  I  can  foresee  who  is  likely  to 
win  or  lose.  [14] 

The  quality  of  the  assessment  and  plan  must  not  be  sacrificed  for  the  sake 
of  expediency.  The  detail,  timeliness,  and  quality  of  the  assessment  are  products  of 
the  intelligence  analysis.  One  conceptual  model  presented  by  Major  Orr  in  a  recent 
paper,  explicitly  includes  the  intelligence  function  (see  in  figure  1).  The  intelligence 
function  is  always  present  in  the  command  and  control  structure,  but  plays  a 
diminished  role  at  the  lower  levels.  The  output  of  the  intelligence  analysis  feeds 
the  decision  making  process  of  the  command  structure  and  aids  in  the  formulation 
of  strategy. 


[8:27] 
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The  intelligence  analysis  as  a  support  function  in  the  decision  making  process 
has  become  so  important  that  it  now  exists  among  government  agencies  whose 
functions  are  to  provide  necessary  analysis.  The  Central  Intelligence  Agency,  for 
example,  created  by  congressional  charter,  provides  the  government  with  wide 
ranging  views  of  the  foreign  affairs  of  other  governments.  The  Defense  Intelligence 
Agency,  as  another  example,  provides  analysis  for  the  Department  of  Defense 
oriented  toward  military  affairs.  The  analysis  of  conflict  situations  is  one  function  of 
such  intelligence  agencies  and  is  the  focus  of  this  research. 


The  Future  of  Intelligence  and  Decision  Aids 


The  explosion  of  information  technology  in  the  20th  century  has 
compounded  the  military  commander’s  problem  of  getting  inside  the  enemy’s 
decision  cycle.  The  variety  of  sensors  ranging  from  radar  to  chemicals  has  extended 
the  human  senses  and  taxed  the  analyst  who  must  sort  the  noise  from  the 
intelligence.  The  military  planner  is  often  overwhelmed  by  the  speed  at  which 
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events  change  and  for  which  operations  must  be  measured  and  carefully  evaluated 
in  the  light  of  increased  knowledge  the  assessment  provides.  The  challenge  is  to 
employ  the  technology  of  the  20th  and  21st  century  to  help  the  commander  make 
better  decisions  in  less  time. 

Looking  at  the  technologies  of  the  next  two  decades.  Air  Force  Systems 
Command  conducted  Project  Forecast  II  to  highlight  the  most  promising  new 
research  areas.  Gen.  Skantze  has  described  one  outgrowth  of  the  study  as  the  "super 
battle  management  station"[ll:32].  The  battle  management  station  would  use 
Artificial  intelligence  (AI)  based  decision  support,  make  high  speed  simulation  for 
planning  "what  if  exercises  and  communicate  in  a  highly  visual  representation. 
With  such  a  battle  management  station,  the  commander  could  greatly  decrease 
decision  cycle  time  and  still  make  quantum  improvements  in  the  quality  of  his 
assessment  and  planning. 

One  of  the  key  technologies  for  developing  the  battle  station  is  AI.  It  has 
received  rapid  recognition  as  the  leading  technology  and  has  enabled  development 
of  the  "expert  system".  Expert  systems,  used  in  decision  support  systems,  can  assist 
judgment  or  choice.  One  example  of  such  a  system  (designed  along  the  lines  that 
General  Skantze  outlined)  is  the  Advanced  Sensor  Exploitation  (ASE)  at  Rome  Air 
Development  Center  [13:105].  Graphics  are  employed  to  display  high  resolution 
radar  and  strike  locator  data  in  a  simulated  battle  management  center.  AI  is  used 
by  the  analyst  within  certain  bounded  problem  domains  to  make  inferences  such  as 
the  message  traffic  flow  and  volume  identifying  the  nature  of  a  given  location.  The 
use  of  AI  languages  in  lieu  of  conventional  languages  lends  many  advantages.  The 
systems  can  be  rapidly  prototyped,  the  knowledge  base  is  formed  in  natural, 
language-like  rules,  and  allows  for  operations  with  uncertain  or  incomplete  data. 


Another  valuable  feature  of  AI  based  systems  is  that  the  logical  chain  of  decision 
rules  can  be  followed  or  displayed  upon  query  to  show  recommendation  logic. 

A  second  concept  flowing  from  Gen.  Skantze’s  battle  station  is  the  real  time 
’what  if  simulations.  Most  of  the  operational  planning  follows  from  the  ’what  if  to 
develop  options.  Application  of  a  game  theory  model  in  this  battle  station  would 
seem  to  be  a  natural  since  the  basis  is  a  conflict  of  two  or  more  players.  One 
application  of  game  theory  ideas  to  real  world  conflicts  is  the  development  of 
conflict  analysis  by  Fraser  and  Hipel  [3].  The  most  appealing  aspect  of  the  conflict 
analysis  method  is  that  it  is  nonquantitative  in  its  modeling  of  sociological  and 
psychological  properties  inherent  in  conflict  situations.  The  relative  preferences  of 
the  players  are  developed  and  resolved  by  mathematical  set  theory  and  logic. 


Following  World  War  II  computer  scientists  began  an  intensive  effort  to 
make  electronic  machines  think,  act,  and  behave  like  humans.  Although  it  seems 
the  computer  has  been  around  for  a  long  time,  it  is  a  relatively  recent  product 
British  and  American  scientists  in  the  1940’s  worked  in  separate  groups  to  bring 
forth  the  electronic  computer.  In  the  early  design,  Alan  Turing,  a  British  scientist 
proposed  that  the  controlling  instructions  fed  to  a  computer  should  be  based  on 
logical  operators  such  as  "or",  "not",  or  "and"  [4:2].  The  advantage  of  such  a  system 
would  be  the  capability  to  manipulate  symbolic  information  such  as  natural 
language.  American  designers,  however,  chose  to  pursue  a  machine  based  on 
numerical  operators  such  as  "+", and  ">".  The  American  design  became  the 
defacto  standard.  The  growth  of  technology  to  the  current  crop  of  super  computers 
has  focused  along  the  numerical  processing.  However,  recent  research  has  revisited 


the  early  design  choices  and  brought  forth  the  interdisciplinary  approach  to 
computer  science  called  Artificial  Intelligence  (AI). 

In  the  the  1960’s  AI  began  to  emerge  from  universities.  Predictions  of 
humanoid  butlers  to  do  household  chores,  machine  translators  that  could  speak  any 
language,  or  robots  that  would  do  dirty  or  dangerous  jobs  abounded  [10:195].  Belief 
that  machines  might  possess  such  human  qualities  gave  rise  to  concerns  that 
machines  might  become  smarter  than  humans.  While  computer  science  is 
developing  at  an  exponential  rate,  the  tasks  of  human  decision-making,  robotics,  and 
speech  have  proven  to  be  more  troublesome  than  first  envisioned.  While  a  total 
solution  has  not  been  achieved,  methodical  progress  in  specific  aspects  of  AI 
problems  has  proven  productive.  One  of  the  most  recent  advances  is  the 
development  of  expert  system  tools  which  allow  the  design  of  computer  decision 
making  or  diagnostic  programs  for  very  specific  applications. 

Expert  Systems 

From  the  outset,  AI  has  worked  to  bring  human  behavior  to  the  computer. 
The  primary  focus  of  artificial  intelligence  is  abstract  problem  solving.  In  contrast, 
the  "expert  system"  or  "knowledge  system"  differs  from  other  AI  techniques  in  that 
knowledge  is  gathered  and  applied  to  a  specific  event  or  problem  just  as  a  human 
expert  would  do.  The  term  "expert"  can  be  widely  applied,  but  a  working  definition 
is  given  by  Johnson,  a  scientist  who  studies  the  decision  making  of  human  experts: 

An  expert  is  a  person  who,  because  of  training  and 
experience,  is  able  to  do  things  the  rest  of  us  cannot; 
experts  are  not  only  proficient  but  also  smooth  and 
efficient  in  the  actions  they  take.  Experts  know  a  great 
many  things  and  have  tricks  and  caveats  for  applying 
what  they  know  to  problems  and  tasks;  they  are  also 
good  at  plowing  through  irrelevant  information  in  order 
to  get  at  basic  issues,  and  they  are  good  at  recognizing 
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problems  they  face  as  instances  of  types  with  which  they 
are  familiar.  Underlying  the  behavior  of  experts  is  the 
body  of  operative  knowledge  we  have  termed  expertise. 
It  is  reasonable  to  suppose,  therefore,  that  experts  are 
the  ones  to  ask  when  we  wish  to  represent  the  expertise 
that  makes  their  behavior  possible.  [17:5] 


Professor  Edward  Feigenbaum,  a  noted  researcher  from  Standford  University  has 
defined  an  expert  system  as: 


...  an  intelligent  computer  program  that  uses  knowledge 
and  inference  procedures  to  solve  problems  that  are 
difficult  enough  to  require  significant  human  expertise 
for  their  solution.  Knowledge  necessary  to  perform  at 
such  a  level,  plus  the  inference  procedures  used  can  be 
thought  of  as  a  model  of  the  expertise  of  the  best 
practitioners  of  the  field. 

The  knowledge  of  an  expert  system  consists  c 
facts  and  heuristics.  The  "facts"  constitute  a  body  of 
information  that  is  widely  shared,  publicly  available, 
and  generally  agreed  upon  by  experts  in  a  field.  The 
"heuristics"  are  mostly  private,  little  discussed  rules  of 
good  judgment  (rules  of  plausible  reasoning,  rules  of 
good  guessing)  that  characterize  expert-level  decision 
making  in  the  field.  The  performance  level  of  the 
expert  system  is  primarily  a  function  of  the  size  and  the 
quality  of  a  knowledge  base  it  possesses.  [1:5] 


The  modeling  of  the  human  expert  has  provided  the  computer  the  capability 
to  perform  difficult  decision-making.  Ideally,  the  expert  system  functions  just  as  the 
human  experts  commonly  do.  For  example,  experts  ask  questions,  apply  prior 
general  knowledge,  and  make  inferences.  Often,  the  problem  presents  the  expert 
with  uncertain  or  incomplete  information  that  must  be  accounted  for  in  solving  the 
problem. 


Research  Problem 


The  specific  research  problem  is  to  assist  the  intelligence  analyst  by 
automating  parts  of  a  conflict  analysis.  Expert  system  technology  will  be  explored  to 


left  the  feasibility  of  capturing  enough  knowledge  of  conflict  analysis  to  develop 
and  implement  a  personal  computer  aid. 

Objective 

The  objective  of  this  research  is  to  demonstrate  the  feasibility  of  blending  AI 
and  operations  research  techniques  by  applying  expert  system  technology  to  conflict 
analysis.  Inherent  in  this  approach  is  the  development  of  a  working  expert  system 
model  that  can  run  on  an  IBM  PC  or  similar  system.  In  pursuing  the  design  and 
development  of  this  system,  limitations  of  the  use  of  small  computer  environments 
as  aids  should  be  understood.  An  evaluation  of  the  system  should  also  provide 
insights  into  future  benefits  to  be  derived. 

Scope 

The  average  intelligence  analyst  brings  a  broad  base  of  perceptual  tools  to 
bear  on  any  one  problem  that  is  far  beyond  the  scope  of  this  research  effort  The 
problem  domain  is  narrowed  to  view  only  events  which  may  be  modeled  as  conflict 
situations.  While  other  tools  are  available  for  assessing  outcomes,  this  work  is 
focused  solely  on  resolutions  of  small  conflict  models.  The  number  of  players  is 
limited  to  two,  and  each  player  may  form  5  options.  These  limits  may  be  readily 
expanded  in  future  extensions  but  serve  to  demonstrate  the  feasibility  of  the 
approach.  This  research  encodes  the  knowledge  base  and  heuristics  of  a  conflict 
analysts.  The  stability  output  was  modeled  as  described  by  Hipel  and  Fraser  [3:14] 
and  displayed  in  a  familiar  form  to  the  analyst 


Assumptions 

This  research  presupposes  that  the  user  of  this  system  is  not  unfamiliar  with 
the  techniques  of  conflict  analysis.  The  user  must  provide  the  system  with 
appropriate  information.  It  is  not  designed  as  a  replacement  for  the  skilled  analyst. 
Instead,  it  is  meant  to  aid  or  advise.  Computer  literacy  is  also  assumed,  a  minimum 
of  normal  startup  and  running  of  programs  under  the  MS  DOS.  The  operator 
should  be  able  to  respond  to  the  normal  DOS  commands  and  be  comfortable  with 
its  operation.  The  government  analyst  frequently  must  assess  various  security 
classifications  of  the  information  and  its  subsequent  products.  This  research  does 
not  attempt  to  assess  the  security  aspects  of  the  work.  This  is  left  to  the  analyst. 

Equipment 

The  equipment  needed  to  support  this  research  maybe  cast  into  two 
categories;  computer  hardware  and  computer  software.  The  computer  hardware 
consists  of  the  electronic  central  processor  unit  (CPU)  and  its  attendant  support 
equipment;  video  monitor,  input/output  devices,  mass  storage,  and  power  supplies. 
The  hardware  system  which  this  computer  aid  supports  is  the  IBM  Personal 
Computer  or  a  close  compatible.  Although  the  target  system  is  the  IBM  PC,  some 
of  the  development  was  conducted  with  the  aid  of  a  VAX  11/785,  Zenith  Z-248  PC., 
and  an  IBM  Advanced  Technology  (AT)  PC.  Since  the  software  needs  specific 
hardware  configurations  in  order  to  function  correctly,  a  minimum  system  will 
require  512k  bytes  of  random  access  memory  (RAM),  a  5.25"  floppy  drive,  a  fixed 
drive  with  at  least  2M  bytes,  and  a  graphics  monitor.  The  development  system  was 
connected  to  the  VAX  11/780  via  a  serial  modem  and  required  serial  interfaces  not 
needed  by  the  target  systems.  The  software  environment  was  run  under  the 


Microsoft  Disk  Operating  System  (MS-DOS)  version  3.0,  3.1,  and  3.2.  Primary 
system  development  was  written  in  Microsoft  C  version  4.0  and  integrated  with 
Knowledge  Engineering  Systems  (KES)  version  23. 

Overview 

The  remaining  chapters  of  this  research  report  describe  specific  portions  of 
the  development  Chapter  II  will  introduce  the  reader  to  the  methodology  used  in 
conflict  analysis.  Chapter  HI  details  the  methodology  used.  Chapter  IV  summarizes 
current  literature  pertaining  to  expert  systems  or  knowledge  based  systems  in  the 
military  and  government  Chapter  V  describes  the  expert  system  design  for  this 
research.  This  chapter  also  develops  the  conceptual  model  for  the  overall  system 
and  examines  the  design  tradeoffs.  Chapter  VI  describes  the  working  prototype  by 
guiding  the  reader  through  a  small  analysis  using  the  system.  Finally,  Chapter  VII 
states  the  research  conclusions,  future  development  extensions,  and  thesis 
recommendations. 
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Introduction 


The  central  issue  in  this  research  is  the  application  of  AI  to  an  operations 
research  technique,  conflict  analysis  [3:6].  This  chapter  presents  an  example  of  the 
conflict  analysis  methodology.  The  steps  in  the  analysis  are  explained  using  a 
hypothetical  NATO  scenario.  Many  of  the  terms,  as  well  as  the  overall  process 
presented  here,  are  applied  in  later  chapters  during  the  development. 

Conflict  is  the  opposition  of  people  or  forces  and  is  ever  present  in  the  real 
world  around  us.  It  is  present  in  small  claims  court,  labor  relations,  business,  sports, 
politics,  and  in  the  most  extreme  case  we  have  war.  A  systematic  study  of  conflict 
can  be  extremely  useful,  especially  if  the  outcome  can  be  forecast  in  advance.  One 
field  of  study  that  has  concentrated  on  this  area  of  conflict  is  game  theory.  Using 
game  theory  as  one  of  his  many  tools,  an  intelligence  analyst  can  structure  and 
ideally  estimate  possible  resolutions  or  outcomes. 

Classical  Game  Theory 


Game  theory  had  its  beginning  in  the  theoretical  work  of  Von 
Neumann.  Von  Neumann  and  Morgenstem  published  their  book  the  Theory  of 
Games  and  Economic  Behavior  in  1944  [16]  and  thus  established  what  has 
commonly  been  termed  classical  game  theory. 

Much  of  classical  game  theory  builds  upon  the  two-person  zero-sum  game. 
Two  adversaries,  called  players,  compete  in  a  game,  and  as  one  wins  the  other  loses 


a  like  amount  Since  the  sum  of  the  net  winnings  and  losses  is  zero  it  is  a  zero-sum 
game.  Each  game  by  definition  involves  some  rules  which  force  the  players  to  take 
certain  actions  or  suffer  some  consequence.  The  players  then  form  their  winning 
strategies  to  achieve  their  goal.  The  goal  may  be  to  maximize  the  winnings,  or  to 
minimize  the  losses.  Whatever  the  goal,  the  strategy  is  chosen  to  achieve  the  desired 
effect  with  the  payoffs.  The  implicit  assumption  here  is  that  the  game  has  value  and 
can  be  modeled  using  payoffs.  Such  payoffs  can  be  measured  in  dollars,  resources, 
utils,  or  any  compatible  unit  of  measure  between  the  players.  A  strategy  is  then 
determined  by  the  cardinal  values  associated  with  the  payoffs.  Greater  or  lesser 
value  achieved  by  strategy  number  one  is  compared  to  strategy  two,  etc.  until  all  the 
options  are  evaluated.  The  rational  player  then  will  pick  the  strategy  or 
combination  of  strategies  to  maximize  or  minimize  the  payoff. 

To  illustrate  the  two  person  zero  sum  game  consider  the  following  game 
given  by  Hillier  and  Lieberman. 

To  illustrate  the  basic  characteristics  of  a  game  theory  model, 
consider  a  simplified  version  of  the  game  called  two  fingered  morra. 

In  this  version,  each  player  simultaneously  shows  either  one  or  two 
fingers.  If  the  number  of  fingers  match,  then  player  I  wins,  say,  $1 
fromjplayer  II.  If  they  do  not  match,  player  I  would  pay  Si  to  player 
II.  Tnus  each  player  has  two  strategies:  to  show  either  one  or  two 
fingers.[5:300] 


The  strategies  1  and  2  are  presented  in  the  payoff  table  in  Figure  2.1.  If  player 
Player  I  shows  one  finger,  then  player  II  would  like  to  have  two.  If  player  I  shows 
two  fingers,  then  player  II  would  like  show  only  one  since  this  would  get  him  the 
best  result.  Without  prior  knowledge  of  the  other  players  strategy,  however,  there  is 
no  clear  best  strategy.  The  choice  of  strategy  in  this  example  is  determined  on  the 
cardinal  values  each  achieves  as  shown  in  the  payoff  table. 
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Player  II 
1  2 


Player  I 


1 

2 


1 

■1 


-1 

1 


MetaGame  Theory 

From  the  preceding  example  of  a  game,  it  is  clear  that  the  formation  of  the 
win-loss  or  value  table  is  needed.  Often  the  values  for  such  a  table  in  real  life  may 
not  be  easily  established.  The  unit  of  measure  often  used  is  the  dollar,  and  that  can 
be  misleading.  How  much  for  example,  is  a  human  life  in  combat  worth  one  tank, 
a  battalion  of  artillery,  or  maybe  a  single  hill.  Placing  values  on  such  things  is 
exceedingly  difficult.  One  method  to  evaluating  games  without  such  quantitative 
values,  is  to  use  mathematical  set  theory  and  form  relationships  which  will  allow  us 
to  solve  the  problem.  In  1971  Howard  publish  his  book  [6]  on  metagame  theory 
which  established  such  a  methodology.  Additional  work  by  Fraser  and  Hipel  [1] 
established  an  extended  metagame  theory,  conflict  analysis.  Conflict  analysis  is  the 
method  used  in  this  research. 


Modeling  a  Hypothetical  NATO  Conflict 

Perhaps  the  best  way  to  understand  the  use  of  conflict  analysis  is  to  use  an 
example  and  to  explore  its  development.  The  example  chosen  for  this  task  is  taken 
from  a  research  paper  by  Capt  John  Yanaros,  an  AFIT  graduate  student.  While 


many  analyses  are  done  in  hindsight,  Capt  Yanaros’  example  presents  a  ’real  world’ 
look  at  a  hypothetical  future  NATO  conflict.  It  is  presented  here  for  demonstration 
of  the  conflict  analysis  technique,  not  as  a  advocate  of  any  particular  point  of  view  of 
the  military  or  political  events  in  NATO.  The  conflict  situation  in  NATO  is  widely 
studied,  providing  grounds  for  many  of  the  assumptions  and  allowing  an  unclassified 
body  of  information  about  the  problem. 

Define  the  Conflict 

The  first  task  in  the  analysis  is  to  define  the  conflict.  The  players,  each 
players  options,  and  general  background  information  pertinent  to  the  structure  of 
the  opposing  players  are  established.  After  the  initial  setup;  the  various  outcomes 
are  generated,  unlikely  outcomes  removed,  preferences  ordered,  and  finally  a 
stability  analysis  provides  possible  equilibriums.  The  following  hypothetical 
scenario  introduces  the  players  and  the  game  structure  which  will  be  used 
throughout  this  report  as  an  example. 


HypQtheticaLSggnariQ 

U.S.  involvement  in  a  Central  American  conflict,  instability  in  the 
Middle  East,  removal  of  US  and  Soviet  tactical  nuclear  weapons 
following  an  Arms  Reduction  Treaty,  and  perceived  weakness  in 
NATO  unity  has  incited  the  Soviets  to  attack  Western  Europe,  the 
Baltic  countries  and  the  Northeastern  Meditteranean.  Prior  to  this 
move,  however,  increased  tensions  signal  the  Allies.  The  anticipation 
of  possible  overt  hostilities  of  the  Warsaw  Pact  (WP)  on  NATO 
territories  calls  for  mobilization  and  a  current  analysis  of  the  friendly 
and  enemy  order  of  battle  (FOB/EOB)  to  verify  current  war  plan 
applicability  and  identify  possible  attack  avenues  of  approach  to  shift 
current  peacetime  general  defense  positions  (GDP)  --  if  necessary  -- 
of  NATO  forces.  Full  mobilization  is  not  accomplished,  however,  due 
to  WP  deception  through  extended  exercises  over  the  past  few 
months.  Analysis  is  done  for  the  NORTHAG  commander 
(COMNORTHAG)  to  provide  him  with  expected  WP  actions  and 
possible  results  of  the  initial  hours  of  the  conflict.  [20:4] 
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Flayers 


...only  the  NORTHAG/2ATAF  area  is  addressed  in  the  analysis. 
Therefore,  the  NATO  player  is  COMNORTHAG  --  referred  to  as  the 
NATO  player  --  and  as  mentioned  ...  WP  will  refer  to  the  second 
player....[5:5] 


Once  the  players  are  established,  they  can  be  represented  in  a  variety  of 
ways.  One  method  that  is  used  in  this  report,  is  to  place  the  players  and  their 
options  in  a  table  format  that  can  be  used  to  represent  the  conflict.  Table  H-2  shows 
the  beginning  of  this  tabular  formation  with  the  players  each  positioned  on  the  far 
left.  The  options  for  each  player  will  follow  under  the  respective  player. 


Table  II-2.  Game  structure  --  the  players 


PLAYERS 

PREFERENCES  VECTORS 

I.  Warsaw  Pact 

II.  COMNORTHAG  (NATO) 

The  objectives  and  an  understanding  of  the  overall  goals  by  a  player  are  used 
in  the  ranking  of  preferences.  The  objectives  also  clarify  some  the  players  options. 
For  this  analysis  the  players  options  and  objectives  are  as  follows: 


NATO/WP  Objectives 

Actions  by  the  players  in  the  ground  conflict  are 
influenced  by  their  respective  national  and  warfighting 
objectives  and  corresponding  doctrine.  Objectives  are... 

1.  Maintain  present  IGB 

a.  mobilize  reinforcements  quickly 

2.  Slow  WP  advance  (decrease  momentum) 


3.  Counterattack  to  defeat  WP 

4.  Restore  pre-war  IGB 

5.  Avoid  a  nuclear  conflict  if  possible 

WP  overall  objective  is  a  reflection  of  USSR  Foreign  Policy  -  ...  For 
the  NORTHAG  region,  the  Western  TVD  wishes  to: 

1.  Secure  primary  northern  FRG  power  source  at 
Hamburg  (Nuclear  Power  Facility  on  tne  Elbe  River) 

2.  Secure  Bremerhaven  (a  port  for  NATO 
reinforcements) 

3.  Flank  to  the  South  into  West  German  and  British 
corps  sectors  to  meet  central  WP  forces  at  Koln.[5:6] 


WP  Options 


The  general  options  are  to  attack  the  NL  Corps 
sector  with: 


1.  1  echelon 

2.  1  echelon  with  an  OMG 

3.  2  echelon 

4.  2  echelon  with  an  OMG 

5.  OMG  only  [5:17] 


1  echelon  (abbreviated  1  ECH) 

2  echelon  (abbreviated  2  ECH) 

Operational  Maneuver  Group  (abbreviated  OMG) 


With  the  Warsaw  Pact  options  established,  we  return  to  the  table  format  and 
place  the  options  for  the  WP  player  under  his  position  in  the  table  (see  Table  II-3 
for  the  format).  Since  the  NATO  options  are  yet  to  be  entered,  we  continue  with 
the  NATO  objectives  in  the  scenario. 
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N#i 


is* 


wav 


PLAYERS 


PREFERENCES  VECTORS 


I.  Warsaw  Pact 

1.  1  ECH 

2.  1  ECH/  OMG 

3.  2  ECH 

4.  2  ECH/  OMG 

5.  OMG 


II.  NATO 


NATO  Options 


...it  is  assumed  that  the  German  Territorial  Army  assets  assigned  to 
the  NL  Corps  sector  will  defend  there.  NATO  Naval  air/amphibious 
options  are  not  considered... 


The  COMNORTHAG  options  are: 

1.  Use  of  present  (Netherland  heavy  armored  brigade) 
force  only.  Wait  tor  NL  reserves  that  are  five  hours 
from  the  peacetime  GDP. 

2.  Move  only  Danish/german  assets  from  the  BALTAP 

grith  SACEUR’s  approval)  -  referred  to  hereafter  as 
A  or  Danish  (GErman  assets  from  the  Schleswig- 
Holstien  area  implied  in  the  notation). 

3.  Move  only  German  Corps  assets  (GE)  into  the  NL 
sector.  Allow  the  British  Corps  to  backup  the  German 
Corps  if  needed. 

4.  Use  the  US  III  Corps  Brigade  (forward)  only. 
Peacetime  GDP  is  located  within  the  NL  Corps  forward 
area.[:18] 

Present  Force  Only  (abbreviated  PF) 

Move  DA  BALTAP  assets  (abbreviated  DA) 

Move  GE  Corps  assets  (abbreviated  GE) 

Use  US  III  Corps  Brigade  (abbreviated  US)  [5:19] 


Table  11*4  now  has  all  the  players  and  their  respective  options.  All 
information  necessary  for  the  representation  of  the  outcomes  has  been  defined.  No 
information,  however,  has  been  provided  about  the  feasibility  of  specific  outcomes, 
or  about  the  players  preferences.  In  order  to  complete  the  initial  table,  the  options 
must  be  uniquely  represented. 


Table  II-4.  Game  structure  -  the  players  and  options 


PLAYERS 


PREFERENCES  VECTORS 


I.  Warsaw  Pact 
1.  1  ECH 


2. 

3. 

4. 

5. 


1  ECH/  OMG 

2  ECH 

2  ECH/  OMG 
OMG 


II.  NATO 

1.  PF 

2.  DA 

3.  GE 

4.  US 


Vector  Representation 


Once  all  the  players  and  the  options  are  defined,  a  binary  representation  of 
the  possible  outcomes  is  used.  When  an  option  is  taken,  we  assign  it  a  value  of  1, 
and  when  not  taken  a  value  of  ’O’.  Thus  for  the  NATO  player 


II.  NATO 

1.  PF  1 

2.  DA  0 

3.  GE  0 


19 


4.  US  0 


the  outcome  [0001]  means  that  the  present  force  only  is  used  (PF).  Notice 
that  the  low  order  1  is  at  the  top  of  the  list,  and  the  higher  order  0  is  at  the  bottom. 
One  additional  point  in  the  WP  option  list,  is  the  way  that  five  options  can  be 
represented  with  just  three.  From  Table  6,  for  example,  an  echelon  with  an  OMG  is 
[101]  and  an  echelon  by  itself  is  [001].  It  is  often  more  convenient  to  work  with 
decimal  numbers,  converting  the  binary  number  into  a  decimal  equivalent.  One 
method  for  this,  is  to  form  the  equivalent  base  number  powers.  The  binary  number 
10100  for  example,  is  represented  as: 

1  x  (2*4)  +  0  x  (2*3)  +  1  x  (2*2)  +  0  x  (2*1)  +  0  x  (2*0)  * 

16  +  0  +  4  +  0  +  0  =  20  (in  base  10). 

To  reverse  the  process,  we  apply  Horner’s  rule  [21:9].  Successively,  divide 
the  old  number  by  the  new  base  number  (10  in  this  case  )  and  note  the  remainder  at 
each  division.  The  number  20  in  base  10  can  be  converted  as  follows: 


20/2  remainder  -  0- 
10/2  remainder  -  0- 
5/2  remainder  ■  1- 
2/2  remainder  *  0- 
1/2  remainder  -  1- 
0  Binary  number  ■ 


I 


—  I  I  I 
■Mil 
10  10  0 


The  use  of  binary  numbers  simplifies  the  problem  structure  in  a  compact 
form.  Because  each  option  can  either  be  selected  or  rejected,  in  a  game  involving  N 
options  there  are  2*N  possible  outcomes  (see  Table  II-5). 
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mwmiimmmm 


options  possibl* 


1 

2 

3 

4 

5 

6 

7 

8 

9 

10 


2  (0  or  1) 

4 

8 

16 

32 

64 

128 

256 

512 

1024 


V 

V 

I? 

V 


In  the  case  of  our  NATO  example  there  are  7  total  options  and  thus,  128  possible 
binary  representations.  The  problem  form  (see  Table  6),  now  lists  all  possible 
outcomes  sequentially  ordered  ,  not  preferentially.  It  is  easy  to  see  how  quickly  a 
problem  with  just  two  or  three  players  and  each  with  two  or  three  options  can 
quickly  become  very  large.  In  performing  this  analysis  by  hand,  each  of  the 
outcomes  must  be  represented  on  paper  and  then  analyzed.  This  is  one  area  where 
a  computer  assisted  program  can  be  a  real  time  saver.  The  computer  can  also  very 
quickly  search  and  sort  the  outcomes,  the  next  step  following  outcome  removal. 


PLAYERS 


PREFERENCES  VECTORS 


II.  Warsaw  Pact 

1.  1  ECH 

3.  2  ECH 

5.  OMG 

I.  NATO 

1.  PF 

2.  DA 

3.  6E 

4.  US 


0  0  0  0  0  0 
0  0  0  0  0  0 
0  0  0  0  0  0 


10  10  10 
0  110  0  1 
0  0  0  1  1  1 
0  0  0  0  0  0 


Outcome  Removal 

Outcome  removal  is  the  next  major  step  in  the  solution  process.  With  128 
outcomes  mathematically  possible,  not  all  outcomes  in  the  set  are  realistically 
feasible.  It  is  highly  desirable  to  reduce  the  set  of  outcomes  to  a  smaller  group, 
which  makes  comparing  them  an  easier  task.  The  form  for  representing  a  removal, 
is  a  combination  of  0’s,  l’s,  and  The  Tand  ’0’  are  in  the  relative  positions  that 
are  to  be  matched,  and  all  other  don’t-care  positions  are  indicated  with  a 
Infeasible  outcomes  generally  are  of  four  types: 

Type  1:  Options  that  are  not  rationally  possible  for  a  single  player  or  that 
may  be  mutually  exclusive.  Type  1  removals  for  this  problem  are: 

A.  (1,1,-;-,-,-)  WP  mutually  exclusive 

B.  (0,0,0;-,-,-,-)  Scenario:  WP  will  attack 

Type  2:  An  option  which  in  the  opinion  of  the  analyst  the  players  would 
never  be  expected  to  accept.  Type  2  removals  in  this  case  are: 


A.  (-t-,-;0,0,0,0) 


COMNORTHAG  is  committed  to  defend  the  NL 
Corps  sector  with  some  forces  for  political  reasons 
and  to  prevent  WP  assured  flanking  success. 


B.  The  NL  Corps  brigade  is  already  at  the  GDP  during 

peacetime;  it  is  reasonable  to  assume  that  they  are  in 
the  sector  on  D-day. 

C.  (0,0,1;-,-,-,-)  Soviet  doctrine  calls  for  OMG  use  in  conjunction 

with  or  in  lieu  of  a  second  echelon  and  will  not  be 
used  if  significant  opposition  in  the  rear  is  likely. 


Type  3:  Options  that  are  not  rational  between  players  can  be  removed.  In 
the  NATO  example,  there  are  no  removals  of  this  type. 


Type  4:  The  last  and  most  judgmental,  is  the  removal  of  an  option  which  is 
not  feasible  for  at  least  one  player  and  which  may  or  may  not  be  feasible  for  the 
other  player.  There  are  two  removals  of  this  type  in  the  example  for  analysis. 


A.  (1,0,1;1, 0,0,0)  A  WP  1ECH/OMG  attack  would  overwhelm  NL 

only  GDP. 

B.  (-,-,-;l,l,l,l)  . Any  combination  of  3  NATO  forces  is  sufficient 

to  delay  initial  invasion.  [20:20] 


After  comparing  each  outcome  with  the  above  removals,  there  are  33 

remaining  outcomes  in  the  set.  The  problem  has  been  reduced  from  128  possible 

outcomes  to  33.  The  remaining  outcomes  do  not  reflect  any  player’s  preferences, 

since  they  are  not  yet  ordered.  A  preference  ordering  is  the  next  step,  performed 

for  each  player  separately.  The  NATO  and  Warsaw  pact  preferences  are  as  follows: 

...The  WP  prefers  to  use  one  or  two  echelon  attacks  over  those  attacks 
using  OMG.  Considering  the  NL  Corps  terrain  (marsh,  rolling  to  flat, 
and  the  Elbe  River)  and  surprise  ...  --  a  second  echelon  attack  is 
preferred  over  a  single  echelon  attack.  The  two  echelon  attack 

ftrovides  mobility  and  speed  into  the  perceived  weak  NL  Corps  area, 
n  summary,  the  WP  attack  option  preference  is: 


(0,1,0;-,-.-.-) 

(0,1,1;-,-,-,-) 

(1,0,0;-,-,-,-). 

NATO  Preference  Vector 


COMNORTHAG  prefers  the  following  priority  of  force  selection  for 
defense  of  the  NL  Corps  sector: 


1.  PF-  the  NL  brigade  is  already  in  position.  Prepared  positions  are 
easier  to  defend  than  hastily  prepared  ones.  No  reshuffling  means 
other  sectors  are  more  prepared  for  WP  attacks  in  their  areas  of 
responsibility. 


2.  US--SACUER  expressed  desire  to  keep  reserve  US  Corps  for 
CENT  AG—  but  COMNORTHAG  has  been  given  the  go  ahead  to  use 
the  US  Brigade  if  he  deems  it  in  the  best  interest  of  NORTHAG. 
This  force  is  already  forward  and  can  be  in  position  quicker  than  the 
GE  or  DA  assets. 


3.  DA-NATO  commanders  perceive  the  BALTAP  region  under  a 
lesser  threat  the  NORTHAG  northern  flank.  Should  a  surprise  attack 
or  shift  of  WP  assets  to  the  BALTAP  occur,  SACUER  has  strategic 
assets  to  use  in  that  area,  such  as  naval  and  amphibious  assault  forces. 


4.  GE-COMNORTHAG  perceives  a  heavy  WP  assault  will  occur  on 
the  I  GE  corps  sector  and  prefers  to  keep  assets  there. 


Obviously  NATO  would  prefer  a  weak  versus  strong  frontal  attack 
and  would  prefer  not  to  fight  an  OMG  in  a  weak  rear  NL  corps  area. 
US  assumes  Soviet  doctrine  holds  and  perceives  a  two  echelon  attack 
only.  Therefore,  the  NATO  player  prefers  the  following  WP  attack 
options,  in  decreasing  order  of  preference: 

1  ECH  (1,0,0;-,-,-,-) 

2  ECH  (0,1,0;-,-,-,-) 

1  ECH/OMG  (1,0,1;-,-,-,-) 

2  ECH/OMG  (0,1,1;-,-,-.-) 


Knowing  the  preferences  of  each  player,  the  set  of  remaining  outcomes  is 
ordered  for  each  player  separately.  The  individual  sets  of  ranked  outcomes  are  the 
preference  vectors  for  each  player.  During  the  ranking  process,  the  outcomes  are 
usually  transformed  from  the  binary  to  the  decimal  form  for  ease  of  display  (see 
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Table  II-7).  The  outcomes  at  the  left  of  the  display  are  the  most  preferred  and  the 
right  most  outcomes  are  the  least  preferred. 


Table  11-7  Preference  Ordered  Outcomes 


WP - ID - 25 - 7 T~ 

42 

90 

“38 

106 

14 

30 

78 

NATO  73  25  41 

89 

105 

57 

10 

74 

26 

42 

Outcomes  Table  continued 

WP  46  94  62 

110 

25 

73 

41 

89 

57 

105 

NATO  90  106  58 

93 

109 

61 

77 

29 

45 

94 

Outcomes  Table  continued 

WP  29  77  45 

93 

61 

109 

NATO  110  62  14 

78 

30 

46 

! 

> 

Stability  Analysis 

» 

j  Once  the  preference  ordering  for  each  player  has  been  determined,  the 

stability  of  each  outcome  can  be  analyzed.  The  stability  process  starts  by 
investigating  possible  unilateral  improvements.  The  subsequent  steps  in  the 
analysis  use  the  unilateral  improvements  (UI),  to  test  for  possible  equilibriums. 
Once  again,  this  process  is  highly  repetitive  and  time  consuming.  Computer 
searches  can  greatly  speed  this  process. 

Unilateral  improvements  are  improvements  in  a  player's  outcome  resulting 
from  that  player’s  change  of  option.  For  example,  the  outcomes  73  and  25  for  the 
NATO  player: 


25 


ft 


NATO  Preference 


WP 


1ECH  1 1 

2ECH0  0 

OMG  00 

NATO 

PF 

1  1 

DA 

01 

GE 

00 

US 

10 

73  25 

The  NATO  player,  shown  on  the  bottom  half  of  the  example,  can  change  the 
DA  option  from  1  to  0  and  at  the  same  time  US  from  0  to  1.  In  making  this  change 
the  NATO  player  changes  unilaterally  and  improves  from  outcome  25  to  the  next 
most  left  outcome,  73.  Since  the  change  moved  his  position  to  the  left  or  in  the 
more  preferred  direction,  the  change  is  a  unilateral  improvement.  This  UI  is  then 
written  vertically  under  its  corresponding  outcome: 


NATO-73  25 
73 


Any  outcome  which  has  no  UIs  is  labeled  rational  and  a  "r"  is  written  above 
it.  Rational,  in  this  case,  means  that  the  player  would  not  rationally  have  a  way  to 
change  from  the  current  position.  To  view  the  all  of  the  binary  outcomes  for  the 
NATO  and  WP,  see  Table  8 . 
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11111100000001111110000000 

00000011111110000001111111 

00000000000001111111111111 


WP 
1ECH 
2ECH 
OMG 

NATO 

PF  11111111111111111111111111 

DA  01010100101011010101010010 

GE  00101100010110110010110001 

US  10011001001101101001100100 


Table  11-9.  Basis  for  UI  Calculation  for  WP 


WP 

1ECH 

2ECH 

OMG 


niililllllll 
11111111111111000000000000 
00000001111111000000111111 


NATO 

PF  11111111111111111111111111 
DA  01001100100110100110100110 
GE  00010110001011001011001011 
US  00101010010101010101010101 


At  this  point  in  the  analysis,  all  outcomes  with  UI’s  have  been  found  and  the 
outcomes  without  UI’s  labeled  as  ’r\  The  next  step  determines  if  a  player  is  stable  in 
a  given  position.  Unstable  means  there  is  a  way  for  the  player  to  improve  his 
position-  a  UI  for  which  the  the  opponent  can  not  stop  or  deter  the  improvement. 
When  an  unstable  condition  is  found  a  ’u’  is  written  above  the  outcome.  If  after 
checking  all  the  UI’s  for  the  preference  vector,  the  player  is  not  able  to  improve 
because  of  the  opponents  options  to  sanction  Ms  improvement  then  an  ’s’  is  written. 
The  ’s’  means  sequentially  sanctioned.  For  example,  NATO’s  outcome  25  ,  there  is  a 
UI  to  73.  Checking  WP’s  outcome  25,  there  is  a  UI  to  26,  which  for  the  NATO 
player  is  less  preferred.  Since  there  is  no  way  to  logically  improve  his  outcome, 


NATO  would  be  sanctioned  by  WP  and  remain  at  25.  NATO’s  vector  25  is 
therefore,  sanctioned,  ’s’.  Tables  II- 10  and  II- 11  have  the  completed  analysis.  All  of 
the  outcomes  have  been  resolved  to  either  Y,  ’s’,  or  ’u’  from  which  the  equilibriums 
can  be  found.  The  equilibrium  which  are  marked  with  an  ’E’  are  where  either  Y  or 
’s’  exist  for  both  players  at  a  given  option.  The  outcome  10,  for  example,  is  ’r’  for 
NATO  and  Y  for  WP  making  the  outcome  10  a  possible  equilibrium  point. 

Finding  the  equilibria  is  the  end  of  the  process,  however,  it  is  good  practice 
to  revisit  many  of  the  earlier  assumptions.  Outcomes  are  checked  for  sensitivity. 
Performing  this  work  by  hand  can  be  very  tedious,  and  the  use  a  computer  is 
recommended. 
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NATO  continued 
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Summary 

Conflicts  can  be  modeled  in  various  ways  but  game  theory  has  concentrated 
in  this  field  since  Von  Neumann  started  it.  Conflict  analysis  is  an  extension  of  game 
theory  and  uses  ordinal  preferences  instead  of  the  value  modeling  of  classical  game 
theory.  The  conflict  analysis  method  has  five  stages  by  which  a  solution  is  sought. 
First,  the  players  and  options  are  identified.  Once  the  options  are  defined,  a  set  of 
possible  outcomes  is  generated.  Third,  the  infeasible  outcomes  are  removed  from 
the  set  of  possible  outcomes.  Next,  the  outcomes  are  rank  ordered  by  preference. 
Finally,  the  stability  is  analyzed  and  possible  equilibrium  outcomes  are  identified. 
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This  chapter  is  a  guide  to  the  methodology  used  in  this  thesis.  It  is  not  a 
detailed  design  guide,  that  is  left  for  Chapter  V.  This  chapter  concentrates,  instead, 
on  the  overview  of  this  research  problem.  Readers  familiar  with  the  general 
methodology  may  refer  directly  to  other  chapters  for  discussions  of  the  various 
issues. 

The  problem  chosen  for  this  effort  was  both  large  and  complex  which 
increased  the  difficulty  of  managing  its  completion.  This  research  does  not  provide 
specific  answers  to  specific  problems,  but  leads  to  understanding  -  which  leads  to 
knowledge.  Since  the  knowledge  in  two  separate  fields  of  study  were  intermingled 
in  this  work,  it  was  important  to  employ  a  systems  approach  to  problem  solving. 
The  systems  methodology  consisted  of  factoring  the  research  problem  into  a  series 
of  subproblems  or  components.  This  methodology  then  solved  each  subproblem  in 
a  step  by  step  manner,  each  step  building  upon  the  previous  component.  This 
chapter  describes  the  systematic  approach  used  and  outlines  the  steps  pursued  in 
this  research. 


Understanding  Expert  Systems 

i 


The  first  task  was  to  understand  the  complexities  of  expert  system 
construction.  The  expert  system  must  aid  a  military  analyst  conducting  a  conflict 
analysis.  Table  III-l  lists  the  steps  normally  associated  with  expert  systems 


development  [12:5-1].  The  product  of  this  development  was  a  tool  which  more 
quickly  and  precisely  performed  many  of  the  mundane  tasks  in  the  conflict  analysis 
methodology.  Many  facets  of  this  problem  were  studied  and  appropriately  scaled  to 
a  reasonable  level  of  effort.  The  second  step  in  the  development  of  a  computer 
tool  for  conflict  analysis  was  the  formulation  of  the  system  requirements. 

Table  111-1.  Expert  System  Development  Strategy 

TI  Analyze  the  System  Requirements 

2.  Acquire  the  Knowledge 

3.  Design  the  Expert  System 

4.  Build  the  Knowledge  Base  File 

5.  Evaluate  the  Expert  System 


System  Requirements 

The  system  requirements  provide  a  guide  that  maps  the  input  into  outputs 
and  identifies  the  processing  functions.  The  real  purpose  in  constructing  the  system 
requirements  is  to  define  in  tabular  form  the  data  and  processes  that  the  prototype 
design  must  implement  (see  tables  in  chap  V  ).  Development  of  the  system 
requirement  tables  enforces  a  structure  on  the  development  process.  It  precisely 
defines  what  the  system  must  do.  For  example,  the  user  (conflict  analyst)  must 
provide  information  about  the  conflict  such  as  the  players,  options,  and  preferences. 
The  system  requirement  tables  define  exactly  the  form  for  these  inputs  (see  table  V- 
2  in  chapter  V).  At  the  culmination  of  the  system  processing,  the  user  expects  a 
stability  analysis  with  possible  equilibriums.  Again,  the  system  requirements  specify 
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the  form  and  processes  needed  to  derive  these  outputs.  Clearly  defined  system 
requirements  also  provide  the  criteria  for  making  important  design  decisions. 
Decisions  on  the  selection  of  expert  tools  and  programming  languages  are 
constrained  by  the  system  requirements.  Often  the  system  requirements  may  grow 
or  change  during  the  development.  The  system  requirements  are  provided  in 
chapter  V  along  with  the  prototype  design  tradeoffs. 


As  with  any  software  development,  tradeoffs  occurred  frequently  in  the 
formulation  of  the  prototype  design.  The  goal  in  implementing  all  of  the  design 
tradeoffs  was  to  optimize  subproblems  of  the  conflict  analysis.  A  limiting  factor, 
considered  at  this  stage  in  the  design,  was  the  nature  of  a  prototype  system.  Time 
and  resource  constraints  limited  the  prototype  in  scope.  The  limitations  while 
acceptable  for  research  were  not  desirable  for  a  full  blown  production  system. 
Thus,  the  prototype  system  demonstrates  only  the  feasibility  of  the  design  approach. 
A  To  extend  beyond  this  prototype  into  a  production  system  would  require  a 
different  level  of  effort  and  tradeoff  decisions. 

The  most  important  decision  in  the  design  phase  occurred  early  in  the 
research.  It  was  the  choice  of  the  expert  system  development  tool.  Many  tools  were 
commercially  available,  but  not  necessarily  available  at  the  Air  Force  Institute  of 
Technology.  No  one  tool  met  all  of  the  needs  of  this  project  and  thus  forced  a 
choice  on  how  best  to  support  the  needed  capabilities.  In  particular,  the  notion  of 
an  embedded  expert  system  narrowed  the  field  rapidly.  Very  few  commercial  tools 
supported  the  embedded  design  concept  and  only  KES  was  available  at  AF1T. 
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A  review  oi  the  Fraser  and  Hipel  text  along  with  papers  and  articles  of 
various  conflicts  revealed  that  the  process  consistently  performed  certain  actions.  In 
conflict  analysis,  the  repetitive  actions,  occurred  in  five  distinct  phases  of  analysis. 
Table  III-2  below  provides  a  flow  chart  of  the  five  phases  and  depicts  their 
relationship.  The  example  in  Chapter  II  also  illustrated  all  five  phases,  as  they 
applied  to  the  NATO  scenario,  ordered  sequentially  as  the  analyst  might  perform 
them.  First,  the  collected  facts  about  the  problem,  players,  and  options  defined  the 
conflict.  As  the  example  from  Chapter  II  showed,  culling  the  information  or  data  to 
provide  a  problem  structure  consumed  a  lot  of  effort.  Second,  the  conflict  yielded  a 
number  of  possible  outcomes.  The  method  of  generating  the  set  of  all  the  possible 
outcomes  varied,  but  a  systematic  approach  ensured  a  total  set  without  overlooking 
a  combination.  Third,  the  analyst  eliminated  infeasible  outcomes  from  the  set  of  all 
possible  outcomes.  Fourth,  the  analyst  preferentially  ranked  the  outcomes  of  the 
various  players.  The  ranked  set  of  outcomes  then  formed  the  preference  vector  for 
each  player.  Fifth,  the  stability  process  and  logic  rules  applied  to  the  preference 
vectors  (set  of  ordered  outcomes),  identified  possible  equilibriums.  At  this  point  a 
sensitivity  analysis  repeated  the  process  with  new  or  reordered  preference  vectors. 
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Define  Players 


i 


V _ 

Generate  Outcomes 


V _ 

Remove  Infeasible< 
Outcomes 


V _ 

Preference  Order 
Outcomes 


V _ 

Stability  Analysis> 


Each  of  the  five  distinct  phases  represented  a  logical  component.  Each  step 
proceeded  in  turn  to  the  next,  building  upon  the  results  of  the  previous  work.  Since 
one  of  the  objectives  in  this  research  was  the  application  of  expert  system 
technology  to  the  process,  it  was  necessary  to  examine  each  phase.  Expert  system 
technology  did  not  work  for  all  of  the  problems,  only  certain  classes  of  problems. 
The  research,  therefore,  tested  each  step  for  suitability  to  expert  system 
development.  Establishing  criteria  to  assess  the  suitability  of  each  step  was  difficult. 
The  criteria  depended  upon  the  capability  of  the  software  and  hardware  tools 
chosen.  As  a  general  guide,  however,  the  criteria  applied  to  the  subproblem  areas 
was  whether  they  were  most  suited  to  solution  by  algorithms  or  by  heuristics  [4:8]. 
The  areas  most  suited  to  heuristics  were  the  ones  deemed  promising  for  an  expert 
system  to  solve.  Not  all  of  the  steps  examined  were  of  a  heuristic  nature  and 


amenable  to  expert  system  development.  Thus,  to  provide  a  useful  computer  tool,  a 
combination  of  conventional  and  expert  system  development  was  necessary. 

The  combination  of  an  expert  system  and  the  conventional  solution  logic 
presented  unique  challenges.  The  standard  approach  in  most  of  the  expert  system 
designs  relied  heavily  on  the  problem  being  implemented  and  run  under  the  control 
of  an  expert  system  design  tool.  Design  tools  vary  in  the  amount  of  control  for 
display  graphics,  communication  with  external  files,  or  execution  of  external 
functions  or  programs.  The  high  degree  to  which  the  conflict  analysis  solution  steps 
interrelated  with  each  other,  suggested  that  the  expert  system  and  nonexpert 
program  functions  needed  direct  communication.  The  most  direct  communication 
occurred  when  both  parts  existed  in  the  same  program.  An  expert  system 
integrated  within  the  conventional  program  and  run  under  its  control  is  an 
embedded  system. 

Embedded  Expert  System 

i  Building  the  embedded  expert  system  occurred  in  three  phases[12:12-l].  The 

first  phase  was  the  development  of  the  control  program  with  all  the  logic  and 
functions  to  carry  out  the  program  except  for  calls  to  the  expert  system  (see  Table 
III-3).  The  exclusion  of  the  calls  from  the  main  program  is  a  practice  used  by 
software  developers  commonly  known  as  stubbing.  The  benefit  of  ’stubbing’  in  the 
calls  to  the  expert  system  was  that  it  allowed  the  program  statements  to  be 
debugged  without  the  added  complication  of  the  expert  system.  Theoretically,  the 
programmer  could  build  an  embedded  system  in  any  programming  language.  Many 
languages  were  considered  such  as  Fortran,  Lisp,  Ada,  Pascal,  Basic,  and  C.  Since 
many  parts  of  the  problem  relied  on  binary  vector  operations  and  matrix  math,  a 
mathematical  or  scientific  language  appeared  necessary.  Hardware  control  and  use 
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of  assembly  language  modules  to  support  the  screen  display  were  included  and 
further  narrowed  the  language  choices.  However,  in  practice  the  researcher 
constructed  the  embedded  expert  system  design  most  easily  using  the  C 
programming  language.  See  reference  [7]  for  a  description  of  the  C  programming 
language. 


Table  III-3.  Phase  I  of  Embedded  System 


Flow  Chart 


— >  Editor  : Source  Code  in  C  (stubbed  calls  to  Expert) 


I 


C  Compiler 


:  Source  »C.obj 


I 


-<-  Linker 


;C.obj  »File.exe  (executable) 


Coaygmiopal  Program  Pevelopmgnt 


The  research  developed  the  C  program  in  a  conventionally  structured 
method.  Structured  programing  formulated  functions,  arguments,  types,  and 
variables  before  writing  any  of  the  program  code.  Many  of  the  program  functions 
derived  their  basic  structure  from  the  system  requirements  (see  Chapter  V  for  more 
detail).  With  each  function  or  procedure  well  defined,  construction  of  the  shared 
parameters  and  data  was  an  easier  task.  A  flow  chart  of  the  program  logic  was  used 
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to  give  a  broad  outline  in  the  development.  The  flow  chart  guided  the  translation  of 
program  control  logic  into  C  program  source  code.  Source  code  was  the  form  of  the 
program  as  written  by  an  editor  and  stored  in  a  normal  ASCII  file.  The  C  program 
compiler  then  translated  the  source  file  into  an  object  code  file,  along  with  a  log  of 
any  errors,  a  memory  map  of  symbolic  names,  and  assembly  code  listings.  The 
object  file  produced  by  the  compiler  combined  with  library  files  and  other  object 
modules  formed  an  input  for  the  linker.  The  linker  then  produced  an  executable 
file  which  operated  from  the  operating  system  command  line. 


Flow  Chart  of  Logic 
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The  verification  of  the  proper  program  logic  was  also  conventionally 
debugged.  The  verification  used  sample  cases  or  reliable  examples  which  produced 
known  results.  The  sample  cases  allowed  the  comparison  of  the  prototype's  output 
against  known  results.  Other  methods  tested  the  nonlogic  errors.  For  example,  the 
compiler  flagged  errors  such  as  syntax  errors  and  logged  them  in  an  error  listing. 
Logic  errors  required  changes  in  the  program  code,  while  either  spelling  or  usage 
corrections  fixed  the  syntax  errors.  The  corrected  source  code  produced  a  new 
executable  file  when  resubmitted  to  the  process  previously  described. 


The  second  phase  in  the  embedded  system  development  produced  the 
knowledge  base  for  the  expert  system  (see  table  IV).  The  development  captured, 
wrote,  and  translated  the  expert  knowledge  into  a  source  program  file.  The  expert 
system  then  parsed  the  source  knowledge  file.  The  expert  system  parser  had  many 
features  similar  to  those  of  a  language  compiler.  It  took  the  source  knowledge  base 
file,  an  ASCII  readable  file,  and  produced  a  binary  file  which  was  readable  only  by 
expert  system  program.  During  program  execution,  the  embedded  expert  system 
read  and  used  the  parsed  knowledge  base  file  at  the  appropriate  time.  The 
knowledge  base  file,  like  any  other  program,  required  debugging.  To  facilitate  the 
process,  testing  and  development  in  a  stand  alone  mode  proved  the  most  successful. 
The  knowledge  base,  in  much  the  same  manner  as  the  C  program,  was  tested  by 
inputting  known  quantities  and  observing  the  results  or  output. 
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Editor  : Source  Knowledge  Base  File 


Expert  System  Parser  : source  »  File.pkb 
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File.pkb  (is  read  at  runtime  by  program) 


Expert  System  Program 


Knowledge  Engineering 

As  discussed  previously,  the  knowledge  base  development  occurred  in  the 
second  phase  of  the  embedded  program  development.  The  knowledge  base, 
however,  was  acquired  by  knowledge  engineering  the  expert  or  sources  of  expertise. 
The  knowledge  engineering  phase  was  crucial  to  properly  capturing  the  facts, 
heuristics,  and  experience  of  the  expert.  The  engineering  process  focused  on  a 
knowledge  base  that  operated  in  a  manner  consistent  with  the  process  that  the 
expert  used.  A  discussion  in  chapter  V  presents  the  expert  system  knowledge  base 
for  this  thesis  in  greater  detail  along  with  the  steps  taken  to  verify  the  knowledge. 

The  expert  and  the  knowledge  engineer  are  usually  not  the  same  individual. 
However,  for  this  thesis  the  author  served  as  both.  Where  outside  expertise  was 
needed  Colonel  O’Connell,  the  AFIT  instructor  for  conflict  analysis,  provided 
additional  guidance.  The  knowledge  base  construction  also  benefited  from 
information  provided  in  the  Fraser  and  Hipel  text. 
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Integration 


The  third  and  final  step  in  the  integration  was  the  testing  of  the  embedded 
knowledge  base  with  the  C  program  previously  developed.  The  communication  and 
calls  to  the  expert  systems  were  debugged,  again  with  the  aid  of  known  cases  or 
results.  After  all  the  parts  were  in  place,  the  process  rapidly  evolved  as  changes 
were  made  to  improve  the  speed,  screen  displays,  or  operation.  Because  the 
different  parts  of  the  program  were  so  highly  interdependent,  it  was  necessary  to  test 
the  changes  in  stand  alone  mode.  This  followed  much  the  same  process  as  the 
development  of  the  initial  program.  After  the  changes  were  functioning  properly, 
they  were  recombined  in  the  integrated  program  and  the  cycle  repeated. 

As  the  development  proceeded,  the  C  language  program  was  supplemented 
with  assembly  language  modules  for  improved  screen  control  and  speed.  The 
process  for  their  development  was  similar  in  that  the  assembly  modules  were 
stubbed  in  the  C  program.  Assembly  modules  for  hardware  detection,  screen 
control,  and  speed  up  were  produced,  debugged,  and  compiled  separately.  Many 
supporting  debugging  tools  were  used.  The  many  tools  used,  allowed  a  timely 
completion  and  much  of  the  work  could  not  have  been  done  without  them.  When 
the  assembly  modules  were  functioning  properly  they  were  added  as  objective 
modules  and  linked  with  the  C  modules  produced  by  the  compiler  to  form  the  final 
integrated  program.  The  resulting  product,  thus  was  a  combination  of  C  procedures 
and  logic,  assembly  language  extensions,  and  the  embedded  expert  system  program 
code. 
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Summary 


The  success  of  any  research  project  depends  in  part  on  the  development  and 
use  of  sound  methodology.  For  this  research  effort  a  systems  approach  was  used  to 
solve  the  problem.  The  overall  problem  was  examined  and  divided  into  constituent 
parts.  Some  parts  were  selected  for  knowledge  engineering  and  solution  an  the 
expert  system,  while  others  were  approached  with  conventional  program  algorithm 
methods.  Parts  which  were  heuristic  in  nature  were  knowledge  engineered  to 
produce  the  knowledge  base  program.  With  the  knowledge  base  requirements  in 
view,  the  systems  requirements  were  established  and  used  to  perform  design 
tradeoffs.  Especially  important  design  tradeoffs  such  as  the  choice  of  a  design  tool 
were  made  early  in  the  development.  The  development  of  the  expert  system  and 
conventional  C  program  proceeded  in  parallel.  The  parallel  development  facilitated 
the  debugging.  Finally  the  two  were  combined  and  tested  with  known  cases  to  verify 
proper  operation. 
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This  chapter  summarizes  the  related  work  of  other  researchers.  The  focus  in 
this  section  is  on  the  specific  contributions  from  these  related  works  which  form  the 
theoretical  underpinnings  of  this  thesis.  Since  this  research  effort  employed  an 
interdisciplinary  solution  methodology,  the  related  works  come  from  different  fields 
of  study. 

The  solution  methodology  employed  in  this  research  was  an  application  of 
artificial  intelligence  and  an  operations  research  methodology,  conflict  analysis. 
While  elements  of  these  subjects  are  discussed  here,  this  chapter  will  not  provide  a 
tutorial  on  either  subject.  The  reader  is  assumed  to  be  familiar  with  such  A 1  topics 
as  production  systems,  forward  and  backward  chaining,  rules,  frames,  and 
constraints.  For  more  detailed  information  on  AI,  the  reader  is  directed  to  books 
written  by  Rich  [9],  Winston  [18],  Barr  and  Fiegenbaum  [2],  while  Fraser  and  Hipel 
describe  conflict  analysis  [3]. 


Artificial  intelligence  is  a  broad  problem  solving  science  that  encompasses 
three  main  areas;  natural  language  processing,  robotics  and  pattern-recognition,  and 
knowledged  based  systems  often  called  ’expert  systems’.  AI  has  expanded  rapidly  in 
the  last  ten  years  with  increased  applications  for  military  problems.  This  research 


followed  that  trend  and  concentrated  in  the  expert  systems  area  for  military 
applications. 


Expert  System 

Rich  [9:191]  provides  a  definition  for  expert  systems  as  follows: 

"An  interactive  computer  system  that  performs  a  task  normally  done 

by  a  human." 

From  the  definition,  there  would  appear  to  be  very  little  that  such  a  system 
could  not  do.  However,  in  practice,  limitations  exist  upon  the  applicability  of  such 
systems.  Only  certain  tasks  in  this  research  were  found  to  be  suitable  for  the  expert 
system  (for  further  discussion  see  Chap  V).  There  are  fundamental  differences  in 
the  operation  of  expert  systems  and  conventional  programs.  The  conventional 
program  is  a  product  of  the  structured  programming  concept.  It  uses  algorithms  to 
manipulate  data  with  tight  constraints  on  the  form  of  such  data.  The  expert  system 
on  the  other  hand,  manipulates  knowledge  by  use  of  heuristics  and  inferential 
processes  [17:18].  The  criteria  for  evaluating  the  suitability  of  candidate  problems 
to  expert  system  development  is  whether  the  problem  is  most  suited  to  algorithms  or 
heuristic  solution  methods. 

Expert  System  Development  Concerns 

Expert  systems  have  unique  problems  which  must  be  considered.  As  the 
name  implies,  an  expert  system  must  have  an  expert.  A  single  expert  is  ideal,  but 
multiple  experts  or  no  expert  are  exceptionally  difficult  obstacles  to  overcome.  The 
expert  must  be  able  to  communicate  his  knowledge  to  the  knowledge  engineer.  The 
’lack  of  common  sense’  in  an  expert  system  may  foster  user  distrust.  The  finite 
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knowledge  available  to  the  system  implies  that  the  system  is,  and  always  will  be, 
limited.  The  knowledge  engineer  has  some  latitude  in  constructing  the  systems 
response.  This  variability  can  mean  that  the  system  responds  properly  to  a  specific 
situation  but  not  in  a  more  general  situation.  The  user,  is  therefore,  uncertain  as  to 
the  reliability  of  the  system  in  a  general  case. 

Expert  Systems  in  the  Military 

While  no  AI  system  for  conflict  analysis  was  found,  a  number  of  AI  systems 
are  used  in  military  decision  making.  One  such  system  is  KNOBS  which  helps 
mission  planning  at  a  TACC  (Tactical  Air  Command  and  Control  Center).  The 
KNOBS,  knowledge-based  system,  is  a  back  chaining,  rule  based,  planner 
developed  by  Mitre  Corporation  [17:293]. 

Another  TACC  tool,  TATR  (Tactical  Air  Targeting  Recommender)  was 
developed  by  the  Rand  Corporation.  TATR  assists  by  planning  and  projecting 
effects  of  airfield  attacks  [17:296].  After  viewing  TATR’s  projections,  the  original 
plan  can  be  updated  and  improved.  The  system  is  a  menu  driven,  rule  based, 
forward  chainer.  Experienced  air  targeteers  were  knowledge  engineered  to  produce 
the  heuristics  and  rules  implemented  in  ROSIE.  ROSIE, (Rule-Oriented  System  for 
Implementing  Expertise)  uses  an  English  like  syntax  for  ease  of  non  programmers 
reading  and  understanding  the  program  logic. 

A  third  system  provides  a  feature  lacking  in  the  first  two,  a  color  graphic 
interface.  The  system  called  SPOT  was  developed  by  SRI  International.  SPOT  is 
an  interactive  planner  for  carrier  aircraft  launches  [1:46]. 
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No  expert  systems  applied  to  conflict  analysis  were  found  in  a  review  of 
current  literature.  A  conventional  program  from  Waterloo  Engineering  Software, 
however,  was  found  which  performed  the  analysis.  The  program  called 
Decisionmaker:  The  Conflict  Analysis  Program  [15:1],  hereafter  called  CAP  was 
described  as  a  comprehensive  decision  support  system  for  strategic  decision  making. 
A  demonstration  version  of  the  CAP  was  obtained  and  evaluated  by  the  author. 

The  CAP  written  in  the  C  programming  language,  runs  on  the  IBM  PC 
computers  or  systems  that  use  the  MS-DOS.  The  program  is  distributed  on  a  5.25 
inch  floppy ,  not  as  a  single  program  but  with  several  files.  It  uses  the  color  graphics 
on  the  computer  system  if  installed.  The  demonstration  version  of  the  program  is 
restricted  to  a  single  predefined  conflict  and  a  fixed  number  of  players.  The 
nondemonstration  version  is  designed  for  larger  models  with  up  to  10  participants, 
30  options  and  1,000  outcomes  [15:2]. 
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The  CAP  solution  process  uses  8  steps  (see  Table  IV-1).  At  any  stage  in  the 
process  some  control  is  afforded  the  user  through  the  use  of  the  keyboard  function 
keys,  F1-F10.  The  function  keys  summon  a  help  menu,  or  allow  access  to  other 
parts  of  the  program.  The  first  step  is  the  entry  of  the  players.  A  minimum  of  two 
up  to  a  maximum  of  10  players  can  be  accepted.  Next  the  user  enters  the  options,  up 
to  a  maximum  of  30  total  options.  The  options  are  either  taken  or  not  taken,  never 
partially  taken.  Third,  the  infeasible  outcomes  are  removed.  The  removal  is  done 


by  manually  entering  the  options  which  are  exclusive  in  a  special  screen  display. 
The  next  stage  ranks  the  remaining  outcomes.  A  mask  of  preferred  options  is 
manually  entered  and  the  program  sorts  accordingly.  The  result  of  the  sort  is 
displayed  and  the  user  is  allowed  to  move  individual  outcomes  in  the  preference 
vector.  Once  the  vectors  are  ranked,  a  stability  anaysis  is  prepared  and  displayed. 
The  program  prompts  to  repeat  actions  for  the  sensitivity  analysis. 

The  CAP  program,  however,  has  some  problems.  The  CAP  user  interface  is 
limited  and  it  provides  little  user  control  of  the  screen  display.  While  some  parts  of 
the  process  are  prompted  and  occur  automatically,  others  require  more  work  from 
the  user.  The  identification  of  the  infeasible  outcomes,  for  example,  is  entirely  a 
user  input.  Once  entered,  the  program  removes  the  outcomes  as  commanded. 
Rank  ordering  of  the  outcomes  is  another  area  in  which  the  user  must  understand 
the  program  commands.  A  controlling  mask  for  the  ranking  operation  must  be 
entered  by  the  user.  Tjeally,  the  program  should  be  smarter  in  its  handling  of  the 
ordering  process  and  less  demanding  of  the  user. 

Summary 

This  review  examined  several  key  A1  expert  system  considerations.  The 
criteria  for  suitability  to  expert  system  development  depended  upon  whether 
heuristics  or  algorithms  would  be  better.  The  Expert  system  needed  a  single  expert 
who  could  communicate  the  knowledge.  The  expert  systems  have  limits  to  their 
knowledge.  Care  must  be  taken  to  understand  where  the  knowledge  base  works, 
and  where  it  does  not  work.  Three  military  expert  system  applications  were 
discussed,  although  none  perform  conflict  analysis.  A  conventional  program  for  the 
resolution  of  conflict  models  was  discussed.  It  performs  all  of  the  functions  of  a 
stability  analysis  through  a  traditional  software  design. 


This  chapter  examines  the  system  design.  The  system  requirements,  design 
tradeoffs,  prototype  design,  and  evaluations  will  be  discussed  in  detail.  The  overall 
process  governing  the  flow  of  construction  was  presented  in  Chapter  3.  The  actual 
’C’  program  code  is  not  discussed  in  this  chapter  but  is  included  in  the  appendix  to 
this  thesis. 


Most  successful  expert  systems  have  at  least  five  major  tasks  associated  with 
their  development. 

These  tasks  are: 


1.  Analyzing  the  Requirements 

2.  Acquiring  the  Knowledge 

3.  Designing  the  Expert  System 

4.  Building  the  Knowledge  Base 

5.  Evaluating  the  Expert  System 


The  actual  tasks  often  vary,  and  the  sequence  of  task  completion  is  subject  to 
overlap  during  the  development.  This  chapter  begins  with  the  system  requirements 


and  draws  upon  the  knowledge  of  a  conflict  analysis.  Chapter  2  provided  a  detailed 
example  of  a  conflict  analysis  and  should  be  reference  for  additional  information. 


Analyzing  the  Requirements 

Traditional  software  development  and  expert  system  design  are  similar  in  the 
first  stage  of  development.  General  information  about  the  problem  domain  must  be 
gathered  so  that  initial  design  decisions  can  be  made.  The  systems  tasks  are 
established  and  the  general  expectations  of  the  users  are  factored  into  the 
man/machine  interface. 

The  system  requirements  in  this  section  will  cover  the  following  areas: 

1.  Identify  the  external  requirements 

(Task  Analysis) 

2.  Determine  the  available  domain  resources. 

3.  Characterize  the  end  users. 

4.  Identify  the  expected  user  environment. 

While  the  requirements  process  would  appear  to  be  fixed  at  the  conclusion  of 
this  process,  it  is  not.  Development  is  an  adaptive  process  that  refines  and 
continually  changes  the  system.  One  of  the  controlling  factors  is  that  as 
development  proceeds,  one  encounters  unexpected  limitations  in  the  hardware  and 
software  tools.  By  providing  solutions,  some  tradeoffs  are  made  in  an  adaptive 
manner.  Thus,  none  of  the  requirements  for  this  system  are  cast  in  concrete, 
instead,  they  continuously  evolve  during  the  adaptive  design  process. 
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The  goal  from  the  beginning  of  this  research  has  been  to  aid  the  military 
analyst  with  conflict  analysis.  This  research  produced  a  prototype  computer 
program  which  demonstrated  the  design  concepts.  While  this  program  is  complete, 
it  is  more  limited  in  scope  than  a  full  production  system.  The  term  conflict  analysis 
is  more  formally  defined  for  this  project  as  the  mathematical  process  developed  by 
Fraser  and  Hipel  which  extended  metagame  game  theory  (see  Chapter  2  for 
example).  Since  the  goal  of  any  analysis  in  a  conflict  is  to  produce  the  winning 
strategy,  this  system  aids  in  that  quest.  The  conflict  analysis  method  models  the 
problem  structure:  identifies  the  players  and  their  options,  eliminates  infeasible 
outcomes,  rank  orders  outcomes,  and  then  performs  a  stability  analysis  and 
identifies  most  likely  conflict  resolutions.  See  Table  V-l  for  comparison  of  inputs 
and  Table  V-2  for  the  outputs  of  current  manual  method,  the  prototype,  and  a  fully 
developed  operational  system. 


REQUIREMENTS  MANUAL 
(Inputs)  METHOD 


THESIS 

PROTOTYPE 


OPERATIONAL 

SYSTEM 


List  Players 

a .  names 

b.  options 

Any  number 
listed  on 
paper 

Accepts  only 

2  players 

Accepts  upto  100 
and  can 

search  Database 

List  the 

infeasible 

outcomes 

Listed  on 
paper 

Generated  by 
Expert  Sys 
consulting 
user 

Generated  Auto¬ 
matically  by 
Expert  System 

Rank  order 
preferences 

Listed  on 
paper 

Sorted, ordered  Automatically 
by  computer  sorts  from 

Expert  Sys  Knowledge  base 

consultation 

Inputs 


The  inputs  for  the  conflict  analysis  actually  come  from  extended  intelligence 
gathering,  historical  study,  or  personal  knowledge.  The  identification  of  the  players 
may  be  a  difficult  problem  in  itself.  For  example,  a  hypothetical  group  kidnaps  the 
head  of  a  company  and  demands  ransom  -  Who  are  the  kidnappers?  Are  the 
kidnappers  controlled  by  external  powers?  Are  the  kidnappers  one  group  or  several 
factions?  Regardless  of  the  situation,  accurately  characterizing  the  players  is  an 
intelligence  function.  The  output  of  the  intelligence  assessment,  should  identify  the 
key  players.  The  example  in  Chapter  2  as  a  case  in  point,  concluded  that  the  players 
were  the  NATO  alliance  and  the  Warsaw  Pact  alliance  in  opposition.  Once  the 
players  are  established  by  the  conflict  analyst,  the  players  options  need  to  be 
determined.  The  information  describing  options  must  be  conveyed  from  the  analyst 
to  the  computer  program  logic.  By  providing  structure  for  this  information  an 
accepted  form  is  used.  Fraser  and  Hipel  use  a  binary  number  representation  for 


the  various  combinations  of  options  to  form  the  outcomes  and  this  representation  is 
used  as  the  standard  for  this  work.  For  example,  two  players  with  two  options  each 
can  completely  represent  the  16  possible  outcomes  as  follows: 

Player 1 

a.  0101010101010101 

b.  0011001100110011 
Player2 

a.  0000111100001111 

b.  0000000011111111 

Decimal:  0  123456789 . 15 

Examine  the  second  column  of  numbers  from  top  to  bottom  and  find  the 
number  [1,0,0,0].  This  outcome  means  that  Player  1  does  option  ’a’  and  Player2  does 
nothing.  The  vector  [0,0,0, 1]  thus  identifies  an  outcome  and  can  be  converted  to  a 
decimal  number.  In  the  case  given,  [0,0,0, 1]  becomes  the  number  T.  See  chapter  2 
for  a  discussion  of  binary  and  decimal  numbers  conversions.  The  user  must  either 
form  the  outcome  on  paper  or  input  it  to  the  computer  for  analysis.  If  a  binary 
number  is  used  to  represent  the  strategies  it  can  be  shown  that  ’2’,  exponentially 
raised  to  the  power  of  the  number  of  options  (2ANUM  OPT),  is  the  total  number  of 
possible  outcome  combinations.  However,  some  of  the  combinations  may  be 
infeasible  and  must  be  removed  from  the  set  of  all  possible  outcomes.  The  user 
identifies  the  outcomes  to  be  removed.  Fraser  and  Hipel  identify  four  types  of 
infeasible  combinations  that  can  be  found  [3:34].  For  example,  [1,1, 0,1]  may  be  an 
impossible  outcome  and  must  be  eliminated  from  the  group  of  all  possible 
outcomes.  However,  the  user  must  supply  the  information  necessary  to  remove 


certain  types  of  outcomes  that  are  logically  or  preferentially  infeasible.  The  last 
input  required  is  the  rank  ordering  of  the  vectors  for  each  player.  From  the 
previous  example  we  may  have  a  decimal  ranking  something  like: 


Player 1  3 

Player2  0 


1  0 


The  ranking  as  displayed  for  Playerl  indicates  that  the  binary  number  ’3’ 
outcome  is  the  most  preferred  outcome  in  Playerl’s  opinion.  Player2,  on  the  other 
hand,  would  prefer  the  ’do  nothing’  outcome  [0,0, 0,0]  as  the  most  desirable  outcome. 
The  user  must  supply  the  ranking,  although  the  knowledge  of  the  options  may  allow 
the  expert  system  to  suggest  an  ordering. 
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Output 

The  outputs  from  the  conflict  analysis  are  the  intermediate  steps  from  the 
analysis  and  stability  results  (see  Table  V-2  for  summary).  The  process  which  map 
the  inputs  into  the  outputs  are  summarized  in  Table  V-3.  The  intermediate  results 
refer  to  the  development  of  what  Fraser  and  Hipel  term  unilateral  improvements  or 
"UI’s".  A  typical  decimal  representation  of  the  UI’s  is  the  decimal  number  under 
each  position  to  which  an  improvement  is  possible,  such  as: 


I 


'  s'  .S  «'•  »s 

v  S  *»  f  >  V m  . 


3 


7 


1 

3 


0 

3 

1 


In  this  example  playerl  can  unilaterally  improve  from  outcome  ’1’  to 
outcome  ’3’  as  the  three  under  the  1  represents.  An  improvement  from  ’O’  to  either 
T,  or  ’3’  is  also  possible  unilaterally.  Using  the  UI’s  allows  one  to  continue  the 
analysis  and  to  classify  vectors  for  their  relative  stability.  Again  returning  to  the 
previous  example,  the  vector  for  each  player  would  be  classed  as  rational  ’r\ 
unstable  ’u\  or  sanctioned  ’s’  according  to  the  methodology  of  the  conflict  analysis. 
The  vector  would  be  output  as  follows: 


Playerl 

Player2 


r  r 

3  7 

r  r 


0  3 


u 


1 

u 

7 


u 


1 


An  equilibrium  occurs  for  outcomes  for  which  both  players  are  either  an  ’r’  or 
’s’.  In  the  example,  3  is  r  for  both  players  and  thus  a  possible  equilibrium  point.  The 
stability  outcome  is  represented  as: 


E  x 

Playerl  r  r 

3  7 

Player2  r  r 

0  3 


x 


u 

1 


u 

7 


x 

u 

0 

r 

1 


Once  the  analysis  has  successfully  completed  all  preceding  steps  leading  up 
to  the  possible  equilibriums,  the  user  would  continue  to  another  conflict  or  adjust 
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the  vectors  to  another  form  and  resolve  the  problem.  The  repeated  variation  of  the 
preference  vectors  is  a  common  form  of  sensitivity  analysis. 


Table  V-2.  System  Requirements  Matrix:  Outputs 


REQUIREMENTS  MANUAL  THESIS  OPERATIONAL 

(Outputs)  METHOD  PROTOTYPE  SYSTEM 


List  of  all  List  on  Display  list  Displays  any 

possible  paper, no  up  to  256  number  of 

outcomes  limit  of  outcomes  outcomes 

num.  outcomes 


Reduced  list 
of  outcomes 
after  infeas. 

List  derived 
on  paper 
no  limit 

Display  limit 
256  outcomes 

Display  any 
number 

List  of  UI's 

List  on 
paper, no 
limit 

Limit 
by  screen 
size  to  15 

Display 

number 

any 

List  outcomes 

List  on 

List  of  up 

Display 

any 

as  r,u,or  s 

paper, no 
limit 

to  256 
displayed 

number 

Resolved 

List  on 

List  of  up 

Display 

any 

Equilibriums 

paper , no 
limit 

to  256 
displayed 

number 

Help 


Verbal  5  help  Context 

explanation  screens  sensitive 

»5  screens 


End  User  and  Environment 

The  prototype  system  is  designed  for  the  AFIT  student  environment.  The 
system  will  be  used  by  either  students  or  researchers  in  conjunction  with  conflict 
analysis  classes.  The  prototype  system  will  aid  in  the  solution  of  problems  usually 
now  done  by  hand.  As  a  prototype,  the  system  may  be  readily  expanded  to  an 
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operational  system  of  possible  use  by  the  CIA,  DIA,  or  other  intelligence  analysis 
agencies.  A  limited  knowledge  of  computer  operation  is  essential.  The  typical 
engineering  graduate  student  at  AFIT  is  a  sophisticated  computer  user  and  more 
knowledgeable  than  is  required  for  this  system.  The  user  must  have  some 
understanding  of  the  Fraser  and  Hipel  text  and  should  expect  a  friendly  computer 
environment,  highly  graphic,  and  windowed.  Context  sensitive  help  and  menu 
driven  screens  are  assumed  as  the  basic  interface.  Since  the  problem 
representations  are  highly  structured  and  in  vector  form,  textual  displays  are  of  little 
value.  The  user  is  assumed  to  be  unfamiliar  with  AI  or  Expert  System  tools. 
Whatever  operations  occur,  they  must  be  highly  structured  and  self  explanatory,  as 
might  be  the  case  in  a  menu  driven  system.  Although  speed  is  not  a  major 
consideration  in  this  design  a  user  becomes  very  bored  with  delays  exceeding  15 
seconds,  thus  the  system  must  respond  in  less  than  15  seconds  or  communicate  at 
least  frequently  on  its  status. 


Equipment  Requirements 

Two  categories  of  equipment,  computer  hardware  and  computer  software, 
are  needed  to  support  this  research.  The  computer  hardware  consists  of  the 
electronic  central  processor  unit  (CPU)  and  its  attendant  support  equipment,  video 
monitor,  input/output  devices,  mass  storage,  and  power  supplies.  One  of  the  major 
decisions  in  the  system  design  was  to  determine  what  computer  system  would  be 
used  to  develop  the  prototype.  The  choice  was  made  to  support  the  IBM  Personal 
Computer  or  a  close  compatible  because  of  the  availability  of  computer  equipment 
and  the  tools  which  were  available  to  custom  tailor  the  environment.  The  system 
could  just  as  easily  have  been  hosted  on  a  VAX  or  mainframe  system,  however,  the 
IBM  PC  is  much  more  widely  used  in  small  applications.  Although  the  target  system 


is  the  IBM  PC,  some  of  the  development  was  conducted  with  the  aid  of  a  VAX 
11/785,  Zenith  Z-248  PC.,  and  an  IBM  Advanced  Technology  (AT)  PC.  Since  the 
software  needs  specific  hardware  configurations  in  order  to  function  correctly,  a 
minimum  system  will  require  512k  bytes  of  random  access  memory  (RAM),  a  5.25 
inch  floppy  drive,  a  fixed  drive  with  at  least  2M  bytes,  and  a  graphics  monitor.  The 
development  system  was  connected  to  the  VAX  11/780  via  a  serial  modem.  It 
required  serial  interfaces  not  needed  by  the  target  systems.  The  software 
environment  was  run  under  the  Microsoft  Disk  Operating  System  (MS-DOS) 
version  3.0,  3.1,  and  3.2.  Primary  system  development  was  written  in  Microsoft  C 
version  4.0  and  integrated  with  Software  A&E  KES  2.3.  Windows  and  screen 
control  support  libraries  from  Star  Guidance  Consulting  were  modified  and  used  in 
the  development. 


The  decision  to  develop  the  prototype  using  the  IBM  PC  computer 
established  many  limitations:  the  lack  of  virtual  memory,  limited  storage  capacity, 
limited  processing  power,  and  software  dedicated  to  the  Intel  8086/8088  CPU 
family.  The  IBM  PC  also  offers  many  positive  benefits  to  the  development.  In 
spite  of  its  lack  of  power  in  comparison  to  larger  machines,  the  thousands  of 
companies  that  offer  software  in  support  of  the  IBM  PC  more  than  makes  up  for  the 
loss.  The  support  for  the  PCs  has  grown  to  the  point  where  color  graphic  displays 
and  easily  customized  user  friendly  interfaces  are  readily  available. 
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To  build  the  expert  system  portion  of  the  prototype,  a  decision  was  made  to 
use  a  commercial  expert  system  tool.  The  number  of  ES  tools  available  is  very  large 
and  growing  larger.  Many  of  the  tools  are  produced  to  operate  in  very  specific 
environments.  Some  tools  are  VAX  or  Symbolics  computer  dedicated  systems  while 
others  are  made  for  the  IBM  PC.  Some  of  the  companies  market  more  than  one 
version  of  their  product  for  a  variety  of  computers.  In  addition  to  the  number  of 
systems  marketed,  the  author  was  constrained  to  work  with  tools  available  at  AFIT. 
Given  that  it  must  be  available  at  AFIT  and  operate  on  the  IBM  PC  family  of 
computers,  the  list  of  tools  was  narrowed  to  just  four  candidates  (see  Table  V-5). 


Table  V-5 .  COMPARISON  OF  EXPERT  SYSTEM  TOOLS 
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input:  Yes 


The  four  candidate  tools  are:  Knowledge  Engineering  System  (KES),  PC 
Consultant  Plus  (PC+),  Insight  2  +  ,  and  Ml.  All  of  the  tools  operate  on  the  IBM 
PC  family  and  are  available  at  AFIT.  The  four  tools  considered  are  all  ruled  based 
systems,  but  only  two  support  a  frame  based  structure.  In  order  to  make  the  choice 
among  the  four  tools,  the  system  requirements  were  used  to  apply  selection  criteria. 
In  particular,  the  weakest  part  in  each  of  the  tools  is  their  lack  of  screen  control 
functions.  How  can  the  outputs  in  Table  V-2  be  displayed  using  one  of  the  tools? 
In  order  to  evaluate  the  suitability  of  each  tool,  a  limited  review  of  each  tools 
sample  programs  were  run.  None  of  the  tools  was  capable  of  directly  handling 
windowed  screen  displays  of  binary  numbers  or  a  stability  table.  Accomplishing  any 
of  the  screen  displays  would  require  an  external  program  or  language  to  handle  the 
input  and  output.  PC  Consultant  does  allow  an  interface  to  PC  Scheme  (a  lisp 
programming  language)  that  could  be  used.  The  other  tools  also  allowed  interfaces 
to  programming  languages;  Assembler,  Fortran,  Pascal,  or  Scheme.  The  basic 
design  concept  (see  Figure  V-l)  that  emerges  at  this  early  stage  is  Input  and  Output 
of  the  analysis  being  performed  by  a  program  written  in  a  language  which  would 
communicate  with  the  expert  system  and  return  a  result  for  display  to  the  calling 
program. 
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Of  the  inputs  identified  by  the  system  requirements,  not  all  were  considered 


suitable  for  expert  system  development.  In  particular,  generating,  sorting,  and 


searching  binary  number  outcomes  are  better  handled  in  the  conventional 


programming  language.  Each  of  the  inputs  is  a  subproblem  in  conflict  analysis  as 
discussed  in  Chapter  3.  They  are  each  used  in  turn  to  construct  the  next  step.  For 
example,  in  order  for  the  list  of  all  possible  outcomes  to  be  generated,  the  list  of 
players  and  options  from  the  previous  step  are  needed.  The  list  of  outcomes  is  then 
used  in  the  following  step  when  infeasible  outcomes  are  removed.  Passing  of  large 
parts  of  the  data  base  or  programs  arrays  between  elements  would  be  needed  to 
support  this  operation.  The  external  communications,  thus,  are  a  key  problem  in 
this  design.  One  of  the  tools,  KES,  offers  a  unique  solution  to  overcoming  some  of 
the  external  communication  problems.  KES  provides  a  version  of  the  expert  tool 
which  can  be  embedded  in  a  C  program.  Like  any  subroutine  or  procedure,  with  the 


expert  system  embedded  in  the  program,  it  has  access  to  the  same  memory. 


knowledge  base,  and  program  arrays.  The  communication  is  thus  internal  and  not 


passed  externally  in  an  interface  through  the  DOS  (see  figure  V-2).  Given  the 


advantages  of  using  the  internal  method,  the  choice  was  made  to  use  the  KES  tool 


in  an  embedded  system  application. 


vjy.v*. 


It  should  also  be  noted  that  in  choosing  KES,  the  programming  language 
must  be  C.  KES  is  distributed  by  Software  A&E  in  a  form  suitable  for  use  with  the 
Lattice  C  compiler.  AFIT,  however,  does  not  have  the  Lattice  C  compiler  but  uses 
the  Microsoft  C  compiler  instead.  Software  A&E  generously  supplied  the  author  a 
special  version  of  KES  compatible  with  the  Microsoft  C. 


User  interface 

The  acceptance  of  a  program  is  often  based  upon  its  user  interface.  Color 
screens,  graphics,  sound  effects,  and  the  general  ’look  and  feel’  of  the  program 
screen  displays  are  important  to  the  user.  No  matter  how  sophisticated  the  math  or 
program  code,  the  user  sees  only  the  interface.  User  friendliness  is  often  quoted  as 
desirable  but  difficult  to  quantify,  measure,  or  provide.  In  designing  the  prototype 
system,  the  author  elected  to  use  color  window  displays  as  the  primary  interface. 
From  the  previous  design  tradeoffs  the  programming  language  was  specified  as  C. 
The  C  language  does  not  in  itself  support  any  input  or  output  functions.  All  of  the 


input  and  output  in  the  C  language  are  added  functions  designed  and  implemented 
in  libraries  of  support  routines.  The  author  used  the  Microsoft  C  library  functions, 
but  these  do  not  support  the  color  windows.  In  order  to  add  a  windowed  capability, 
a  support  library  of  routines  from  Star  Guidance  Consulting  (The  Window  Boss) 
were  added  to  the  standard  libraries.  By  calling  the  routines  in  the  window  support 
library,  control  of  the  color  window  displays  was  greatly  enhanced. 

The  main  working  screen  is  composed  of  four  separate  working  windows  (see 
Figure  V-3).  The  title  window  is  placed  at  the  top,  a  player/option  window  on  the 
left,  the  preference  window  is  on  the  right,  and  at  the  bottom  is  the  command 
window.  See  Chapter  VI  (a  users  guide)  for  more  information  on  the  use  of  the 
windows.  Not  displayed  are  the  control  panels  and  expert  system  communication 
screens.  When  needed,  the  support  screens  appear  on  the  screen  in  response  to  the 
users  commands. 


Figure  V-3.  User  Interface  Display 
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The  main  C  procedures  developed  to  implement  the  system  requirements  are 
provide  in  Table  V-7.  Their  functions  are  discussed  in  the  following  paragraphs. 
The  C  source  program  code  is  provided  in  appendix.  Each  procedure  in  the  Table 
V-7  corresponds  to  a  section  of  the  C  source  code. 


Table  V-6.  Division  of  Duties  Between  C  and  KES 


Function 

KES 

Task 

Obtain  Players 

X 

Input 

Generate  Outcomes 

X 

Process 

Find  infeasibles 

X 

Process 

Remove  lnfeas. 

X 

Process 

Rank  Preferences 

X 

Process 

Display  Vectors 

X 

Output 

Find  UIs 

X 

Process 

Stability  Analysis 

X 

Process 

Find  Equilibria 

X 

Process 

From  the  inputs  the  user  provides  to  the  program,  a  system  process  is 
completed  by  either  KES  or  a  specific  C  procedure  (see  Table  V-6).  The 
identification  of  infeasible  outcomes,  for  example,  is  completed  by  the  KES  section 
using  a  consultation  of  the  user  through  a  special  window.  Once  the  consultation 
has  been  completed,  KES  passes  information  internally  back  to  the  C  program  and 
the  next  procedure  started.  A  list  of  the  C  procedures  and  what  they  do  is  listed  in 
Table  V-7.  The  internal  C  procedures  that  interface  KES  into  the  C  program  are 
listed  in  Table  V-8.  A  description  of  each  KES  interface  command  is  provided  in 
the  comments  in  the  C  source  code  in  the  appendix.  For  greater  detail  on  how  the 
commands  work,  the  reader  should  refer  to  the  KES  users  manual.  The  ’main'  C 


procedure  is  the  controller  for  all  operations  and  the  sequence  for  the  order  in 
which  procedures  are  called. 


i 


I 

Table  V-7.  C  Program  Procedures 


Procedure 

sound 

classic 

snderror 

sndconfirm 

sndwarn 

laff 

popup 

displogo 

dispwork 

instruct 

userhelp 

user_colors 

diagnostic 

con2bin 

con2dec 

Generate 

Removvec 

Findsame 

stable 

solve 

simul  sanct 
equilibrium 
fintable 
ui  review 
main 


Function 

Makes  the  sound  effects 

Series  of  sounds  to  form  music  tune 

Series  of  sounds  to  signal  error 

Series  of  sounds  to  signal  confirmation 

Series  of  sounds  to  signal  warning 

Series  of  sounds  to  signal  quitting 

Procedure  creates  control  panel 

Creates  opening  logo 

Creates  the  four  main  screens 

Creates  instruction  display 

Creates  user  help  screen 

Creates  change  color  screen 

Creates  diagnostic  screen 

Converts  decimal  number  to  binary 

Converts  binary  to  decimal 

Creates  array  of  outcomes 

Removes  outcomes 

Point  to  outcome  in  other  players  list 
Find  UIs 
Find  r,s,u 

Check  simul.  sanction 
Find  equilibriums 
Create  stability  table 
Display  all  UIs 
Controls  flow  of  execution 


t 
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Table  V-8.  C  Procedures  for  Expert  System  Interface 


Piocedure  I 

KESreceivemesg 
KES_give_value_str 
KES_g_members 
KES  Id  kb 


Function 

Displays  message  from  KES 
Gets  attribute  value  from  user 
Gets  class  members  from  user 
Loads  knowledge  base 


Evaluation 


In  the  design  and  construction  of  the  prototype,  three  main  sample  inputs 
tested  the  logic.  Comparison  of  the  sample’s  known  results  with  the  prototypes 
output  provided  clues  for  debugging.  In  addition  to  debugging,  correct  responses 
from  the  prototype  provided  confidence  in  the  system  operation.  The  testing  of 
specific  sections  of  the  prototype  logic,  required  cases  which  used  the  logic  in  the 
section  under  test.  For  example,  the  testing  of  simultaneous  sanctioning  logic 
required  an  example  that  contained  a  simultaneous  sanction  in  the  result. 

The  three  primary  test  cases  originated  from  examples  used  in  the  Fraser  and 
Hipel  text.  The  first  test  case  was  the  game  of  chicken  [3:252]  modeled  as  a  conflict. 
Table  V-9  lists  the  possible  outcomes  for  the  first  test  case.  The  outcomes  when 
entered,  tested  the  input  functions  of  the  prototype  system.  The  stability  table 
derived  by  the  prototype  from  the  inputs  was  compared  with  the  known  results  (see 
Table  V-10).  The  test  case  outcome  ’3’  provided  the  test  for  the  simultaneous 
sanction.  Several  iterations  in  the  debugging  process  produced  the  proper  error 
free  logic  operation.  The  first  test  case  also  provided  checks  on  the  functions  for  U I 
identification.  Although  not  a  very  large  or  exhaustive  test  case,  the  first  case 
provided  a  good  check  of  communication  among  the  various  functions  in  the 
program. 


0  10  1 


Playerl 

Swerve 

Player2 

Swerve  0011 

Decimal  0123 


Player2  r  S  r  u 
Swerve  1320 
1  2 


Child  A E  x  x  x 
Take  r  u  r  u 

10  3  2 
1  3 

Child  B  r  r  u  u 
0  13  2 
1  0 


The  third  test  case  was  larger  and  required  a  far  greater  number  of 
operations.  Limits  on  the  data  arrays  and  communications  between  functions 
received  further  checking  by  case  three.  The  third  case,  the  Cuban  Missile  Crisis 
[3:15],  also  provided  increased  confidence  in  the  prototype  operation  (see  Table  V- 
13  and  Table  V-14). 
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US 

Airstrike 

Blockade 


010101010101 

001100110011 


USSR 

Withdraw  000011110000 

Escalate  000000001111 

Decimal  0123456789  1011 


Airstrike 

Blockade 


x 

u  u 
5 
4 


r  u 
11  9 

11  11  11 


SSR 

Withdraw 

Escalate 


u  u  u 
3  11  9 

7  7  5 

3  1 


The  test  cases  all  produced  results  in  less  than  a  second.  Several  runs  were 
completed  and  identical  results  boosted  the  confidence  in  the  prototype  operation. 
Inputs  to  the  screen  updated  without  flicker  or  noticeable  pause.  The  prototype  met 
or  exceeded  the  time  goal  of  operations  not  lasting  more  than  15  seconds. 

The  user  interface  was  tested  by  AFIT  student  volunteers  who  provided 
comments  on  the  operation.  The  dislikes  and  likes  were  adaptively  corrected  and 
incorporated  in  the  interface  during  the  development.  Improvements  such  as  the 


user  color  default  control  and  sound  effects  were  a  direct  result  of  the  evaluation 
comments. 

Summary 

The  system  requirements  were  identified.  The  design  of  the  prototype 
program  to  aid  conflict  analysis  was  outlined.  A  single  expert  system  could  not 
handle  the  input  and  output  requirements.  A  composite  design  was  developed  in 
which  the  expert  system  would  handle  some  the  of  the  tasks  and  be  embedded  in  the 
C  program  written  to  handle  the  user  interface  for  input  and  output.  The  user 
interface  was  designed  as  a  windowed  display.  The  system  processes  were  divided 
between  the  expert  system  and  the  C  program.  Procedures  were  then  designed  to 
implement  the  logic  needed.  The  logic  of  the  prototype  was  tested  with  sample 
cases.  Evaluation  the  user  interface  was  provided  by  selected  volunteers.  Likes  and 
dislikes  were  adaptively  corrected  in  the  development. 
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This  chapter  explains  how  to  start  and  use  the  computer  program  developed 
in  this  thesis.  The  reader  is  assumed  to  have  a  working  knowledge  of  the  IBM  Disk 
Operating  System  (DOS)  or  the  equivalent  Microsoft  version.  This  chapter  does  not 
provide  detailed  language  or  programming  instruction  but  should  enable  a  user  to 
install  and  use  Oracle.  This  program  is  primarily  a  tool  for  the  analyst  and  assumes 
the  user  has  a  working  knowledge  of  conflict  analysis  methodology. 

This  chapter  illustrates  the  operation  of  Oracle  and  provides  examples  of 
DOS  commands  to  start  to  it.  Some  confusion  may  result  as  to  what  is  to  be  typed 
by  the  user,  and  what  is  to  be  displayed  by  the  computer.  The  convention  ”sed 
throughout  will  be  the  user’s  response  in  italic  characters,  and  the  computers 
response  in  non-italic  characters.  For  example,  to  execute  the  DOS  command  to 
display  a  directory  listing  of  the  default  directory-  type: 

C>  DIR 

The  ’C>’  is  the  computer  display  of  the  DOS  prompt  character.  The  user 
types  ’DIR’,  without  the  apostrophes,  and  presses  carriage  return  (cr). 


InstaUatiPQ 


The  conflict  analysis  program  (Oracle)  is  not  copy  protected  and  may  be 
freely  copied.  Since  the  program  is  not  copy  protected,  it  will  run  from  either  a  hard 


disk  drive  or  floppy.  However,  due  to  its  size  a  hard  disk  drive  is  highly 
recommended.  Before  attempting  to  install  the  Oracle,  the  user  should  ensure  that 
the  minimum  essential  equipment  for  operation  are  met  (see  Table  VI-1).  The 
Oracle  is  an  executable  file  which  is  not  in  a  "type"  or  "list"  readable  form. 
Compiled  under  the  Microsoft  C  compiler,  Oracle  will  run  any  any  IBM  PC, XT, AT 
or  close  compatible  computer.  It  has  been  tested  successfully  on  Zenith  248,158  and 
IBM  AT,PC.  Since  optional  installed  hardware  is  automatically  detected,  differing 
configurations  of  video  and  communication  hardware  presents  no  problem.  To  best 
use  its  color  windows,  a  color  video  card  or  EGA  display  is  recommended,  but  can 
be  operated  without  them.  A  hard  driw  is  optional  but  at  least  512k  of  memory  is 
needed;  640k  or  more  is  highly  recommended.  As  presently  configured,  memory 
beyond  the  640k  barrier  is  not  accessed  or  used  by  this  program.  Oracle  will 
operate  with  either  IBM  or  Microsoft  DOS  but  needs  version  2.0  or  later  to  reliably 
use  its  windowing  displays.  Operation  of  the  program  with  DOS  earlier  than  2.0 
version  may  produce  unpredictable  results  and  is  not  recommended.  Oracle  will 
automatically  test  the  DOS  version  and  set  its  video  displays  accordingly. 


Table  VI-1.  Minimum  Essential  Equipment 
Computer:  IBM  PC  or  compatible 

Video:  Color  or  EGA  recommended 

Memory:  512k  minimum 


Storage: 


Hard  Drive  is  recommended 
Floppy 


DOS: 


IBM  DOS  ver  2.0  or  greater 
MS  DOS  ver  2.0  or  greater 


The  Oracle  may  be  copied  onto  the  floppy  or  hard  disk  of  choice  with  the 
"diskcopy"  or  "copy"  command.  For  example,  to  copy  the  Oracle  from  a  floppy  in 
drive  ’A:’  to  a  hard  disk  named  ’C:’  and  rename  it  to  CONFLICT,  type: 

C>  copy  A:ORACLE.EXE  OCONFLICT.EXE 

Once  the  Oracle  is  installed  in  the  default  directory  it  may  be  run  by  typing 
its  file  name.  For  example,  to  run  the  Oracle  which  has  been  copied  to  the  hard 
disk  drive  ’C:’  and  named  "conflict.exe",  type: 

C>  CONFLICT 

While  the  main  program  will  operate  without  the  knowledge  base  program 
the  knowledge  base  file  must  be  in  the  same  directory  as  the  main  program  file  in 
order  to  use  the  expert  knowledge.  If  the  parsed  knowledge  base  file  is  named 
"expert.pkb"  then  copy  expert.pkb  into  the  same  directory  as  the  "conflict.exe"  with 
the  same  copy  commands  as  before. 


To  begin  the  Oracle  start  the  computer  with  normal  power  and  "boot  up"  the 
DOS.  If  the  terms  "bootup"  or  DOS  are  not  familiar  to  the  reader,  then  refer  to  the 
computer  operating  instructions  and  DOS  operating  guide  for  the  computer  being 
used.  After  the  computer  is  started  and  the  DOS  prompt  is  displayed  (  usually  a 
prompt  like  ’C>’  ),  you  may  begin  by  typing:  CONFLICT  (enter-key).  If  the  user 
wishes  to  use  some  of  the  special  features  that  can  be  set  with  the  command  line 
switches  (see  table  VI-1),  then  in  addition  to  typing  the  filename,  type  a  space 
followed  by  the  switches.  For  example,  to  start  the  program  without  any  of  the 
sound  effects  turned  on  type: 

C>  CONFLICT /s 


After  a  brief  time,  the  logo  screen  with  the  opening  banner  will  appear 
followed  by  some  sound  effects  (see  Figure  VI-1).  When  the  sound  effects  are 
completed  the  program  prompt-  "Press  any  key  to  Begin"  will  appear  at  the  bottom 
of  the  screen.  You  may  press  any  key  on  the  keyboard  and  the  program  will 
proceed  to  the  next  information  screen  and  halt  with  a  short  beep  from  the  speaker. 
The  information  screen  contains  a  brief  program  description  in  a  windowed  display 
as  well  the  system  time  and  DOS  version  number  (see  Figure  VI-2).  Again  "Press 
any  key  to  Begin"  and  the  program  setups  the  work-screen  for  the  conflict  to  be 
analyzed.  If  the  user  wishes  to  start  up  the  program  and  go  directly  to  the  main 
setup  screen  bypassing  the  opening  banners,  then  the  /f  command  line  switch  (see 
table  VI-2)  can  be  used. 
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ure  VI- 1.  Opening  Logo  Screen 


Figure  VI-2.  Explanation  Screen 


The  Oracle  expects  to  step  through  the  analysis  in  an  ordered  manner  as 
follows: 


In  a  separate  window  on  the  left  side  of  the  display  which  is  titled  "Player" 

1.  Enter  the  Player  1 

A.  Option  1 

B.  Option  2 

C.  Option  3 

D.  Option  4 

2.  Enter  the  Player2 

A.  Option  1 

B.  Option  2 

C.  Option  3 

D.  Option  4 


3.  After  the  players  and  options  are  entered  the  window  directly  to  the  right 
automatically  displays  a  list  of  possible  outcomes.  Just  press  the  (enter-key)  and  the 
window  with  the  outcomes  is  cleared  and  the  program  proceeds  to  next  step. 


4.  The  command  window  at  the  bottom  of  the  screen  will  prompt  for  -Enter 
the  Preference  vectors  for  playerl.  Either  a  decimal  or  binary  representation  is 
allowed. 


5.  After  the  playerl  preference  are  entered  the  command  window  again 
prompts-Enter  the  Preference  vector  for  Player2. 


6.  The  program  again  pauses  until  the  (enter-key)  is  pressed.  The 
reference  vectors  will  be  cleared  and  the  window  will  then  display  the  Final 
lability  Analysis. 


7.  The  program  will  pause  and  wait  for  the  user  to  either  end  the  session 
with  another  (enter-key)  or  *h’  for  the  help  panel. 


^  8.  By  using  the  help  panel,  one  can  revisit  the  various  parts  of  the  analysis. 

To  select  an  option  use  the  arrow  keys  on  the  number  pad  to  place  the  cursor  at  the 
option  you  want  to  select  and  then  press  (enter-key). 


9.  When  in  doubt  just  follow  the  instruction  in  the  command  window  at  the 
bottom  of  the  screen. 


/S 

Silent 

Disables 

sound  effects 

/f 

Fast 

Bypasses 

the  opening  screens 

/diag 

Diag 

Opens  a 

diagnostic  screen 

/e 

Expert 

Enables 

the  expert  system 

/kb 

Knowledge  Enables 

a  new  knowledge  base  file 

Playerl 

Immediately  following  the  instruction  screen,  the  program  sets  up  a  title  at 
the  top  and  three  separate  windows  below  it.  Each  window  serves  a  separate 
function  and  has  its  own  color  to  distinguish  it.  The  left  side  of  the  screen  becomes 
the  player  and  option  window.  A  title  at  the  top  of  the  player  window  is  displayed  as 
"Player".  The  bottom  five  lines  of  the  screen  become  a  command  and  entry  window. 
A  title  at  the  top  is  displayed  as  "Command"  and  whenever  a  command  is  prompted 
a  short  beep  from  the  speaker  follows.  The  right  side  of  the  screen  becomes  the 
largest  window  and  displays  the  preference  vectors  in  a  form  similar  to  the  tables 
used  by  Fraser  and  Hipel.  The  program  will  halt  automatically  at  places  where  the 
user  is  to  enter  or  take  some  specific  action.  When  the  pause  in  execution  occurs,  a 
prompt  for  the  desired  input  is  displayed  in  the  command  window  at  the  bottom  of 
the  screen  along  with  the  speaker  beeping.  Thus,  the  first  pause  at  which  a  user 
must  input  some  information  is  the  command  to  enter  the  first  player.  The  user  can 
type  from  the  keyboard  any  set  of  letters, (a-z,  or  A-Z)  as  legal  values.  Entry  of  a 
number  or  illegal  value  results  in  a  short  beep  on  the  speaker  from  the  program  and 
the  entry  is  subsequently  ignored.  Note,  that  the  ’spacebar’  is  not  a  legal  value,  so 
keep  the  names  and  phrases  short  without  spaces.  The  name  of  the  first  player  can 


1? 

a 
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be  edited  while  being  typed,  with  the  delete  and  back  space  keys.  During  the  entry 
of  the  name  the  letters  appear  in  the  player  window  as  they  are  typed  in  the 
standard  window  colors.  Once  the  (enter-key)  is  pressed,  however,  the  name  is 
entered,  highlighted  with  a  color  change  to  a  red  background,  and  can  not  be  edited 
with  the  edit  keys.  If  an  error  occurs  in  the  entry  of  the  program  players  after  they 
are  entered;  continue  to  the  end  of  the  entry  stage  with  a  series  of  (enter-key)  and 
select  the  ’h’  panel  to  restart  the  game. 

After  the  the  first  player  is  entered  and  highlighted  with  the  red  background, 
the  program  halts  for  the  first  option  of  player  1.  Again,  legal  values  are  any  letter 
from  the  keyboard  which  are  checked  by  the  program.  Since  limited  space  for  the 
options  is  available  they  should  be  kept  to  short  phrases  on  the  same  line.  When  the 
option  is  entered  with  the  (enter-key)  the  program  steps  to  the  next  option  unless  it 
is  the  fourth  option  or  an  extra  (enter-key)  is  pressed.  Anytime  the  ’empty  (enter- 
key)’  is  detected  the  program  proceeds  to  the  next  logical  step  in  the  analysis.  If  in 
doubt  about  what  is  needed  at  any  point  in  the  program,  check  the  command 
window  for  instructions. 

Plaver2 

When  the  command  window  requests  the  entry  for  player2,  it  is  entered  in 
the  same  manner  as  playerl.  The  same  limitations  apply  to  the  legal  values.  The 
program  will  only  accept  two  players.  Three  or  more  players  can  not  be  handled  by 
this  prototype.  The  options  may  be  any  number  from  1  to  four  for  either  player. 
For  example,  Playerl  may  have  two  options  while  player2  has  four  options.  When 
an  empty  (enter-key)  or  the  fourth  option  is  entered  the  program  steps  to  the 
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Preference  Vector  window.  A  short  beep  follows  each  prompt  in  the  command 
window  unless  the  silent  mode  (/s)  was  select  at  program  startup. 


generate  Outcomes 

After  the  players  and  options  are  known  to  the  Oracle,  it  generates  a  list  of 
outcomes  and  displays  them  in  the  vector  window.  The  outcomes  are  presented 
with  the  decimal  value  in  a  blue  background,  and  the  binary  vector  in  standard 
colors  on  the  screen  in  the  row  corresponding  to  their  option.  This  format  is  the 
same  as  that  used  by  Fraser  and  Hipel  in  the  conflict  analysis  text.  The  generated 
outcome  display  is  not  ordered,  it  only  shows  possible  outcomes. 

Preference  Vector  Entry 

The  next  pause  in  the  program  follows  with  a  prompt  to  enter  playerl’s 
preference  vectors  from  the  command  window  (see  Figure  VI-3).  The  player  is 
shown  in  the  vector  window  highlighted  in  a  red  background.  The  command 
window  is  expecting  a  decimal  number  (0-9).  If  a  ’  +  ’  is  entered  instead,  the  input 
switches  to  a  binary  input  mode  i .  which  only  (0  or  1)  is  allowed.  Again,  legal 
values  are  checked  and  illegal  values  are  beeped  and  ignored  as  before.  The 
numbers  can  be  edited  as  long  as  the  enter-key  has  not  been  pressed,  by  using  the 
back  space  or  delete  keys.  After  entry,  the  only  option  to  correct  an  entry  is  to 
restart  the  vectors  for  that  player  with  the  help  window,  discussed  below.  The  order 
in  which  the  vectors  are  entered  is  important.  The  first  vector  is  the  left  most  vector 
and  thus  the  most  preferred  vector.  The  entry  proceeds  in  decreasing  order  of 
preference  until  all  the  vectors  are  in  the  system.  An  empty  (enter-key)  will  stop  the 


entries  and  step  to  the  next  players  preferences.  Continue  until  both  players  are 
completed. 
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The  last  display  in  the  analysis  occurs  after  the  information  for  the  players  is 
entered.  The  command  window  prompts  for  a  CR,to  continue  or  ’h’  for  help.  The 
CR,  to  continue  causes  the  final  table  to  be  computed  and  displayed  in  the  vector 
window  (see  Figure  VI-4).  The  equilibriums  each  in  its  own  little  green  square,  are 
placed  above  the  outcomes.  If  it  is  an  equilibrium  then  an  ’E’  is  placed  in  the  green 
square  if  not  then  ’x’.  Below  the  equilibriums  are  the  stability  values  ’r’,’s’,’u\  or  ’S’ 
each  of  which  is  in  its  own  little  red  background  square.  The  r,s,u  represent  the 
same  meanings  as  the  conflict  analysis  conventions.  The  ’S’  is  a  simultaneous 
sanctioned  vector.  Below  the  stability  values  are  the  decimal  outcomes,  and  UI’s. 
Only  the  first  four  UI’s,  if  any,  are  displayed  due  to  space  available.  More  UI’s  can 
be  seen  by  selecting  the  review  UI’s  option  from  the  help  panel.  If  more  than  15 
outcomes  are  involved,  only  the  first  page  of  15  is  displayed.  The  command  window 
will  prompt  for  the  subsequent  pages  to  be  displayed. 


Figure  VI-4.  Stability  Table  Screen  Displa; 


EM  *4  0 

s:::: 

:JX3Q-hQ|h 

ECO 

3  CD 

o  « 

2sii: 

=  <  O  *4 

O 

H::H 

!*•  K  3  ~  *4  O 

3  *4 

CD  CC 

25" 

1h  *4 

EHXPOh 

3  O 

ID  *4 

H:::: 

E*4 

:J  *4 

:M  K  |,h 

ECO 

3  « 

r  n 

siy 

H«C 

...... 

H  x  ponnn 

3  » 

h 

ECO 

U;:;; 

I  xpnciH 

t.  r> 

as:: 

X  3  *4  c* 

3  *4 

ID 

siy 

E  XfcCt 

«•  r> 

HgH 

X  ?  h  4  O  D 

3  cc 

© 

XPD«« 

*.  CD 

HjH 

I  KlO« 

»  ♦ 

o 

|j| 

£:  M  (.« 


g 


ft  • 

4  4» 

u  • 

■o  ~ 
js  m 

4*  O 

a 

«  mm 

co 

g 


y  yv*V  *V4*.y,V v;\v*V*v*%;»\V*S  *  *’ Cv  V'V *4*.* fc%V  V,v;v \*  w»v*KV v  v- 


W*>sV 


CR--QUIT  or  h--HKLP 


If  Oracle  is  started  with  the  /e  command  line  option  the  expert  mode  is 
enabled.  The  program  will  proceed  to  the  player  entry  point  just  as  before. 
However,  once  the  players  are  entered,  the  outcomes  are  generated  and  a  special 
dialog  window  with  the  expert  system  opens  in  the  center  of  the  screen  (see  Figure 
VI-5).  The  primary  difference  in  the  expert  mode  is  that  no  manual  entry  of 
outcomes  is  made.  The  system  prompts  for  mutually  exclusive  outcomes  (see  Figure 
VI-6).  After  a  brief  question  and  answer  session,  the  the  system  removes  infeasible 
outcomes  and  displays  the  remaining  outcomes  (see  Table  VI-7).  The  expert 
window  will  automatically  open  again.  This  time  for  ranking  the  outcomes  into  a 
preference  vector.  After  the  question  and  answer  session,  the  preference  vectors 
are  displayed. 

Once  all  the  the  outcomes  are  entered,  the  next  carriage  return  starts  the 
stability  process.  The  final  table  is  displayed.  The  user  may  then  quit  or  use  the 
help  panel  to  revisit  any  part  of  the  process. 


VI-5.  Expert  System  Opening  Screen 


Figure  VI- 


VI- 7.  Ranking  of  Outcomes 


Help  Panel 


Whenever  the  command  window  at  the  bottom  of  the  screen  prompts  "Cr,to 
continue  -’h’  for  help"  the  help  window  is  available.  Enter  the  ’h\  that  is  a  lower  case 
h  with  no  quote  marks.  A  popup  window  will  open  with  6  options  listed  (see  Table 
VI-3).  To  select  one  of  the  options  move  the  cursor  with  the  up,  down,  left,  right 
arrow  keys  on  the  key  pad.  When  the  cursor  is  on  the  desired  option  press  the 
(enter-key)  and  the  option  will  be  executed.  If  no  option  is  desired  just  enter  the 
ESC  key.  The  popup  control  panel  will  be  erased,  the  previous  screen  display 
restored,  and  the  speaker  will  beep  in  response  to  the  ESC.  The  next  command  is 
prompted  in  the  command  window.  If  instead  of  no  option,  the  Playerl,  Player2 
vectors  are  selected  the  program  returns  to  the  entry  stage  for  the  appropriate 
player  and  continues  forward  from  that  point.  New  Game  as  its  name  implies  starts 
a  new  game.  Review  UI’s  will  allow  a  full  view  of  UTs  for  both  players  in  order  then 
return  to  the  command  window.  The  help  screen  will  display  the  instruction  screen 
which  has  a  short  summary  of  the  commands  (see  table  VI-4).  The  diagnostic  panel 
is  for  program  configuration. 
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Table  VI-3.  Popup  Control  Panel 
_ CONTROL  PANEL 


Player- 1  Vec  Reentry 
Player-2  Vec  Reentry 
New  Game-Start  Over 
Help  Screen-Commands 
Diagnostic  Panel 
Review  UIs-Full  Page 
Expert  Outcome  Removal 

ESC —  to  quit  1 1 
Cursor-  to  option,  then 
press  RETURN  for  action. 


Table  VI-4.  Help  Screen  Panel 

_ HELP  SCREEN _ 

DOS  VER  3.30  at  Thu  May  21  10:12:30  1987 

CONTROL  COMMANDS 
+  Switch  to  binary  input 

h  Get  popup  control  panel 

T  Set  operation  flag  to  True  value 

F  Set  operation  flag  to  False  value 

exit  program  and  quit  from  vector  stage 
cr  Step  to  next  program  phase 

COMMAND  LINE  SWITCHES  FOR  STARTUP 

/e  Call  KES  during  start 

/f  Bypass  the  opening  screens 

/diag  Call  diagnostic  screen  before  starting 

/s  Silence  the  sounds 

/kb  filename  Use  different  Knowledge  base 
Press  any  key  when  ready  to  Begin 


The  diagnostic  panel  is  used  in  the  debugging  of  the  program  but  provides 
some  user  control  of  program  features.  Some  of  the  diagnostic  features  can  be  set 
by  command  line  switches  before  the  program  is  started.  Once  the  program  has 
been  started,  however,  the  only  way  to  dynamically  change  any  of  the  features  is  to 
use  the  diagnostic  panel  (see  Table  Vl-5).  The  "Call  KES  for  expert"  is  one  example 
of  a  feature  that  can  be  started  by  switch  (/e)  or  set  during  program  operation  by 
setting  the  operation  flag  to  a  TRUE  value.  The  flag  is  set  by  following  the  prompts 
at  the  bottom  of  the  screen  and  entering  a  T  for  true  or  F  for  False.  Once  the  T  or 
F  is  entered  the  value  opposite  the  feature  is  set  to  the  appropriate  value  in  a  red 
highlighted  box.  The  prompt  at  the  bottom  of  the  screen  is  erased  and  the  next 
feature  is  prompted.  The  last  prompt  is  for  changing  the  window  default  color 
scheme. 

Unlike  previous  features  the  color  default  prompt  opens  a  window  in  the 
center  of  the  screen.  Three  windows  from  the  main  screen,  the  Player,  the 
Preference,  and  the  Command  screens  can  be  recolored  with  different  colors.  The 
first  screen  is  the  player  screen  and  is  labeled  as  such  in  the  new  window  opened. 
The  window  remains  in  place  as  the  user  cycles  the  colors  by  use  of  the  arrow  keys 
on  the  keyboard.  The  up  and  down  arrow  keys  will  change  the  foreground  colors, 
while  the  left  and  right  arrow  keys  change  the  background  colors.  Pressing  the 
arrow  keys  will  cause  the  window  to  be  recolored  in  a  new  color  with  each  press  of 
the  key.  If  the  arrow  keys  are  pressed  enough  times  the  colors  will  repeat.  Pressing 
the  up  arrow  for  example  may  change  to  a  blue  which  in  six  or  seven  more  key 
presses  will  once  again  be  displayed  as  blue.  The  down  arrow  will  step  back  to  last 
color  displayed.  The  left  and  right  arrows  operate  in  similar  manner.  When  the 
colors  are  finally  as  desired  press  the  enter  key  and  the  color  combination  will  be  set 


and  the  window  change  to  the  next  screen  to  be  colored.  After  stepping  through  all 
of  the  windows  the  program  will  return  to  the  main  screen  in  the  new  colors.  The 
logo,  help,  and  instruction  windows  are  not  user  configurable. 


Table  VI-5.  Diagnostic  Panel 

DIAGNOSTIC  PANEL 

DOS  VER  3.30  at  Thu  May  21  10:17:29  1987 
Program  is  writing  direct  to  memory  TRUE 
Call  KES  for  expert  FALSE 

Colors  are  default  values  TRUE 

Direct  Memory  Writes 
Enter  T,F,  or  cr  to  accept 


Summary 

This  chapter  has  explained  the  features  of  the  the  Oracle.  Typical  user 
operations  were  explained  and  the  various  commands  used  in  the  program  were 
given.  Many  of  the  operating  screen  displays  were  used  to  illustrate  the  options 
available  to  the  user.  With  the  explanations  in  this  chapter  a  reader  should  be  able 
to  install,  configure,  and  operate  the  Oracle. 
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This  research  effort  culminates  with  the  development  of  a  prototype 
computer  program  which  solves  conflict  analysis  models.  The  computer  based  tool 
is  highly  interactive  and  makes  use  of  multiple  windowed  displays  for 
communication.  This  system  performs  most  of  the  tedious  calculations  and  then 
displays  the  stability  tables  using  color  graphics  for  easy  comprehension.  This 
prototype  uses  an  expert  system  embedded  within  the  program  that  applies  many 
facts,  rules,  and  heuristics  to  the  problem  solving  process.  The  embedded  expert 
system  makes  the  system  easier  to  use  and  understand. 

The  prototype  system  can  be  separated  into  two  main  functional  areas.  The 
first  is  the  embedded  expert  system  and  its  contributions  to  the  solution  process. 
The  expert  system  guides  the  analysis  through  consultations  with  the  user.  Once  the 
problem  is  well  defined  in  terms  that  the  machine  can  use,  it  is  fed  to  the 
conventional  computational  logic  for  resolution.  The  embedded  expert  system  is 
able  to  make  extensive  use  of  the  prototype’s  windowed  displays  and  screen 
graphics.  Without  the  embedded  interface,  the  expert  system  would  be  a  text  only 
display.  The  embedded  design  also  allows  a  much  greater  control  of  where  and  how 
the  information  is  provided. 

The  second  functional  area  is  the  conventional  program  logic  to  which  the 
expert  system  feeds  the  data  and  parameters.  The  main  program  is  written  in  the  C 
programming  language  with  assembly  language  modules  to  take  advantage  of  the 
speed  and  hardware  control.  The  bulk  of  the  searching,  sorting,  and  mathematical 


computations  are  performed  in  this  section.  The  conventional  section  is  also 
responsible  for  managing  the  screen  displays  and  the  man/machine  communication. 

The  successful  implementation  of  these  parts  of  the  overall  conflict  analysis 
into  the  prototype  answers  the  research  problem  and  objective. 

Intended  Use  of  the  System 

The  current  prototype  is  intended  to  demonstrate  the  applicability  of 
embedded  expert  system  technology  for  aiding  an  operations  research  methodology, 
conflict  analysis.  It  is  not  intended,  as  a  foil  scale  production  system  for  use  in  a 
major  problem  solution.  It  is,  however,  capable  of  performing  all  the  necessary 
steps  for  problems  which  are  small  enough  to  meet  its  limitations.  One  possible  use 
for  this  prototype,  is  to  aid  students  studying  the  conflict  analysis  method.  Most  of 
the  problems  which  occur  in  the  text  for  the  conflict  analysis  [3]  are  small  enough  to 
be  solved  using  the  prototype.  The  prototype  should  be  extended  at  a  later  date  to 
larger  problems,  and  rehosted  on  more  powerful  computers.  Only  larger  computer 
versions  will  be  able  to  handle  the  problems  which  often  occur  in  the  real  world. 

Comments  on  the  C  Language 


Many  articles  have  appeared  recently  debating  the  use  of  C  as  opposed  to 
Lisp  for  development  of  expert  systems.  Both  languages  have  good  features,  but  the 
inability  of  Lisp  to  support  the  assembly  language  modules  needed  for  the  machine 
hardware  is  a  major  shortcoming.  In  addition.  Lisp  was  slower  in  its  execution  while 
C  allowed  the  use  of  machine  registers  for  fast  executions.  The  most  attractive 
feature  of  the  C  code  is  the  portability  among  differing  CPU’s.  C  is  not  without 
shortcomings,  however.  While  it  is  a  very  powerful  language,  the  C  source  code  is 


cryptic  and  hard  to  follow.  This  makes  a  C  program  difficult  to  maintain  or 
understand.  Eventually,  both  languages  will  probably  support  the  features  needed, 
however,  for  the  present  only  C  seems  to  have  the  flexibility  this  research  needed. 


Comments  on  KES 

The  focus  of  the  development  in  this  research  was  to  embed  the  expert 
system  within  the  application  program.  KES  was  the  only  product  which  supported 
this  function.  As  supplied  by  Software  A&E,  KES  included  C  language  library 
modules  that  could  be  compiled  and  linked  with  the  application.  Other  systems  take 
a  different  approach.  They  prefer  to  either  make  external  calls  or  compile  and  run 
from  within  the  expert  system.  The  greatest  obstacle  is  the  lack  of  program  and 
screen  control  which  this  forces  upon  the  programmer.  KES  has  the  same 
limitations  in  screen  and  program  control  when  it  runs  as  a  stand  alone  program. 
However,  the  embedded  KES  is  not  limited  except  by  the  applications  screen  and 
program  control.  It  functions  almost  like  a  subroutine  or  procedure  in  the  program. 
One  negative  feature  of  KES,  when  embedded,  is  the  method  by  which  KES  exits 
back  to  the  calling  program.  When  finished,  the  exit  whether  from  an  error 
condition  or  normal  termination,  forces  an  exit.  It  exits  not  only  from  KES,  but  the 
application  as  well.  This  occurs  due  to  an  undocumented  feature  of  the  ’stop’ 
command.  Removing  the  ’stop’  from  the  actions  section  of  the  KES  program 
corrects  this  problem. 

A  second  undesirable  feature  is  the  disabled  ’explain’  and  ’why’  commands  in 
the  embedded  mode.  Normal  operation  of  a  KES  consultation  is  greatly  improved 
with  the  ’explain’  command.  Operation  without  it  is  possible,  but  not  as  useful. 


This  research  effort  should  be  continued  through  further  research  and 
development.  The  prototype  demonstrates  that  the  embedded  expert  system  is  a 
sound  approach.  The  system  is  well  suited  to  aid  students  in  conflict  analysis  classes. 

If  KES  is  selected  for  the  expert  tool  in  future  research,  the  developer  should 
wait  for  the  next  version.  Work  performed  on  the  older  versions,  may  or  may  not  be 
compatible  with  newer  versions.  The  newer  version  may  add  improved  uncertainty 
operations.  The  newer  version  is  also  reported  to  have  corrected  the  problems 
found  in  this  research. 

Recommendations  for  extensions  to  the  prototype  in  this  research  are  of  two 
types.  They  are  C  language  and  AI  extensions.  Improvements  in  the  sorting, 
searching,  and  file  operations  could  benefit  the  C  execution  speed.  For  larger 
problems,  the  computation  speed  becomes  important.  The  current  prototype 
automatically  uses  the  math  coprocessor  chip  if  stalled.  Since  not  all  systems  have 
the  optional  chip,  performance  can  suffer.  In  addition,  the  current  version  of  the 
prototype  does  not  support  printer  or  file  operations.  A  feature  that  is  needed  for 
any  serious  work  in  future  versions  is  printer  support  of  the  windowed  displays.  The 
user  is  currently  limited  to  using  DOS  screen  print  functions  for  hard  copy  prints  of 
the  results.  Unfortunately,  not  all  computer  systems  support  the  screen  print 
functions.  Printer  support  is  an  area  that  would  require  several  C  language 
extensions.  C  language,  or  possibly  assembly  language  modules,  would  be  needed 
for  save  file  operations.  The  user  could  store  several  different  problems  in  separate 
files  and  run  them  without  repeating  the  whole  process. 

Besides  work  on  the  C  modules,  the  knowledge  base  in  the  AI  portion  can  be 
expanded.  Extensions  to  include  conflict  specific  knowledge  as  opposed  to  the 
general  problem  logic  should  be  investigated.  The  knowledge  base  can  be  easily 


rebuilt  without  any  changes  to  the  prototype  using  the  KES  parser.  The  customized 
knowledge  bases  would  increase  the  flexibility  of  the  system  allowing  less  expert 
analysts  the  benefit  of  the  system. 

Finally,  one  area  of  particular  importance,  would  be  the  addition  of  conflict 
analysis  hypergames.  The  prototype  in  this  research  did  not  provide  any  means  to 
solve  an  N-level  hypergame.  The  prototype  did  not  allow  any  uncertainty  in  the 
execution  of  options  or  outcomes.  This  may  be  an  artificial  constraint  that  limits 
real  world  problems.  Conflict  analysis  allows  for  problems  which  involve 
uncertainty  to  be  modeled.  One  technique  is  the  introduction  of  hypergames  into 
the  model.  Since  hypergames  involve  uncertainty  or  misinformation  among  players, 
AI  would  seem  well  suited  to  the  problem. 


Appendix  A 


This  appendix  contains  the  C  source  code  for  the  Oracle.  The  C  source  was 
written  using  the  Microsoft  version  4.0  compiler.  All  of  the  main  body  of  code  is 
contained  here.  Not  included  in  this  section  are  any  of  the  ’include’  files  with  the 
predefined  routines. 


/* - 7 

/*  Thesis  Program  Shad  and  Intarfaoa  7 

/* - V 

/*  7 

/*  Rotlln  J  Lutz  */ 

/*  28-04-87  Version  4.5  7 

r - 7 

/*  Software  Tools  uaad:  7 

/*  7 

/*  C  Language  Compiler  7 

/*  (MoroaoftVar4.0)  7 

/*  copyright  ©Mtoroeoft  7 

/*  7 

/*  Window  Bom  7 

/*  (Ver  3-87 )  7 

/*  copyright  ©Star  Guidance  Consulting  7 

/*  7 

/*  7 

/*  Knowiegde  Engineering  System  (KES)  7 

/*  (Vsr  2.3  modified  for  MSC)  •/ 

/*  copyright  ©Software  A&E  7 

/*  7 

/*- - 7 

♦Include  "KES.IT 

♦Include  “WINDOWS.H-  /•  Uae  so 

♦Include  “STDUB.H"  /•Usem 

♦Include  TIME.H" 

♦Include  'MUSIC.  H" 

♦dellns  UARROW  0x48  /‘define scar 

♦define  DARROW  0x80 

♦define  LARROW  0x4b 

♦define  RARROW  0x4d 

♦define  ESC  0x01 

♦define  RET  0x1c 

♦define  SPACE  0x30 

♦define  STRINQSIZE  80 

♦define  MEM  S1ZE50000L 


/*  Uae  screen  display  lib  •/ 
/*  Uae  math  lib  functions  */ 


/‘define  scan  codes  */ 


stalk)  Int  exp  flg  -  FALSE; 
static  Int  userdrflg  -  FALSE; 
static  int  kes_wn_open  -  FALSE; 
static  Int  fasMIag  -  FALSE; 
static  Int  must_doeeJt  -  FALSE; 
static  Int  si  lent  Jig  -  FALSE; 
static  mt  sort  jig  -  FALSE; 


/* - 7 

/*  Setup  some  of  the  screen  odors  7 

/* - 7 

static  Int  RedYel  -  v_setatr (RED, YELLOW, O.BOLD) ; 
static  mt  Cyn_Blk  -  v_setatr(CYAN,BLACK,0,0) ; 
static  int  Btu_Blu  -  v_setatr (BLUE, BLUE, O.BOLD) ; 
static  Int  Blu_Wht  -  v_setatr(BLUE, WHITE, 0,0) ; 


■tatto  int  BkWht  -  v_eatatr  (BLACK, WHTTE.0,0) ; 

•tatto  M  CynJMtt  -  v_satatr  (CYAN, WHITE, 0,0) ; 

Ml to  M  W*~B*  -  vjsatatr  (WHITE,  BIACK.0,  BOLD) ; 

•tatto M GmJMit  -  v^Mtatr (GREEN, WHTTE.0, BOLD); 
•tatto  IntYaTom  -  vjsatatt  (YELLOW, GREEN, 0, BOLD); 
■tatto  Int  RsdJMrt  -  v_satatr  (RED  WHITE, 0,0); 

•tatto  Int  Gm_Bttc  -  v_aatatr  (GREEN, BLACK.0,0); 

/* - 7 

/*  Stnaotur*  DEF  tor  windows  •/ 

/* - 7 

stnjct  mitam  { 

Int  r, 
into; 
char  *t; 

Int  rv; 

}; 

struct  pmenu  { 

Intfm; 

Int  Im; 

struct  mitam  aom[2S]; 

>; 

/. - ./ 

/*  structure  definition  for  help  wind  •/ 

r - 7 

•tatto  struct  pmanu  popinfo  -  { 

00, 06,  { 

01, 02,  ■  Plsysf-1  Vac  Rsantry  ",  1, 

02,02,"  Playar-2  Vec  Reentry  ",  2, 

03, 02,  “  New  Game-Start  Over  *,3, 

04,02,*  Help  Soraan-Commands  ",  4, 

05, 02.  *  Diagnostic  Panel  ",  5, 
08,02,'  Rsviaw  Uls-FuH  Page  ',6. 

07, 02, "  Expert  Outcome  Removal",  7, 
10. 02,  "ESC-  to  quit  II  ‘,0, 

11, 02,  "Cursor-  to  option,  than ",  0, 

12, 02,  "press  RETURN  for  action ",  0, 

00. 00,  “,00  } 

>; 

W1NDOWPTR  w0,  wl,  w2,  w3,  w4,  wS,  w6,  w7 ; 


/* - 7 

/•  Sound  routines  •/ 

/* - 7 


sound  (duration,  tons) 
int  duration,  tons; 

{ 

long  k,l,dur; 

Int  l,m,n; 
outp(0x43,0xb6); 
k- 0k 144138; 
l«k/tone; 

Outp(0x42,l%0x100); 


outp  (0*42, I/Ox  1 00) ; 

m-lnp(Qx8l); 

mft-OMf; 

n»m; 

m  |-0k3: 

outp(0N81,m); 

dur  ■  Qong)280*duration; 

tor(l-0;l<  -dur;l  +  +); 

outp(0xti1,n); 

> 

/* - 7 

/*  Produce  opening  Sound  routines  */ 
/*  duration  -  .01  tec  */ 

/*  freq  -  hertz  •/ 

/* - 7 

void  dassJcO 

{ 

eound(20,B) ; 
eound(20,0) ; 
eound(20,A) ; 
eound(20,B) ; 
eound(20,D) ; 
sound  (20, C) ; 
sound  (20,  C); 

•ound(20,E); 
sound  (20,  D) ; 
sound  (20, D) ; 
sound  (20,01) ; 
sound  (20, FS) ; 
sound  (20, 01) ; 
sound  (20, D) ; 
sound  (20, B); 
sound  (20,0) ; 
sound  (20 » ; 
sound (20, B) ; 
sound  (20, C) ; 
sound  (20, D) ; 
sound  (20, E) ; 
sound  (20, D) ; 
sound  (20,C) ! 
sound  (20, B) ; 
sound  (20^) ; 
sound  (20, B) ; 
sound (20,0) ; 
sound (20, FSL1) ; 
sound  (20,0) ; 
sound  (20  hA)  ; 
sound (20, DU)  ; 
sound  (20, FSC1) ; 
sound  (20 » ; 
sound  (20,C) : 
sound(20,B) ; 

•ound(20» ; 
sound  (20,  B) ; 
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sound (20, G) ; 
sound  (20  ,A) ; 
sound  (20, B) ; 
sound(20,D) ; 
sound  (20, C) ; 
sound  (20, C); 
aound(20.E) ; 
sound(20,D) ; 
sound  (20,0) ; 
sound  (20, G1)  ; 
sound  (20, FS) ; 
sound  (20,01) ; 
sound  (20, D); 
sound  (20,  B) ; 
sound  (20, G) ; 
sound  (20.A) ; 
sound  (20, B) ; 
sound  (20, C) ; 
sound  (20, D) ; 
sound  (20, E) ; 
sound  (20,0) ; 
sound  (20, C) ; 
sound(20,B) ; 
sound  (20^) ; 
sound (20, B) ; 
sound  (20, G) ; 
sound (20, FSL1) ; 
sound  (20,  G) ; 
sound  (20.A) ; 
sound  (20.OL1) ; 
sound  (20, FSL1) ; 
sound  (20»; 
sound  (20, C); 
sound  (20,  B) ; 
sound  (20^) ; 
sound  (20,  G) ; 
sound  (20,  DC1); 
sound  (20,  BL1); 
sound  (20, GL1); 
sound  (20,147); 
sound  (20, 124); 
sound(1 20,96); 

> 


/* - 7 

/*  Produos  opining  Sound  routlnss 

/*  duration  -  .01  stc 

/*  Iraq  »  hsrtz  7 

/* - 7 

void  sndsrrorO 

( 

tound  (10,440); 
sound(10,220); 

> 


voldsnd  oonfirmO 


aound(10,440); 

aound(10,880); 


{ 


} 

void  snd_wam() 

{ 

sound  (20, 100); 

} 

voMlaffO 

{ 

sound  (EIGHTH,  C) ; 
sound  (5,20000) ; 

•ound  (EIGHTH, C) ; 
sound  (5,20000) ; 

EREST; 

sound(OUARTER,C) ; 
sound  (5,20000) ; 

sound  (EIGHTH,  Q) ; 
sound  (5,20000) ; 

sound  (QUARTER,*) ; 
sound  (3,20000) ; 

sound  (QUARTER,  FL1) ; 
sound  (5^0000) ; 

Q_RE8T; 


sound  (EIGHTH,  F) ; 
sound(5^0000) ; 


) 

/*- 


Popup  function 
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popup(psgs, row, ool, width, hslghtstrib.bstrlb.mx.cflsg) 

/*  video  pag*  */ 

/•  window  -  uppsr  row/col  */ 

/*  window  -  hslght  &  width  */ 

/*  pointer  to  popup  menu  struct  */ 
/*  does  on  return  strike  tug  •/ 

I*  attributes  •  window  &  border  */ 


int| 
int  row,  ooi; 
int  width,  height; 
struct  pmenu  *mx; 
int  cflag; 

Ui  it,  »  •  “ 

nil  CV1D|  OlW| 

{ 

Inti; 


r 


V 


WINOOWPTR  w,  /•  window  pointer  •/ 

static  WWOOWPTRwpeave;  /*  e  piece  to  remember  it  •/ 

Into;  /*  key  scan  eode,,obar  */ 

••■tie  winopn  ■  FALSE;  /•  window  currently  open  flag  •/ 

dado  Indx  -  0;  /*  last  open  window  Item  index  */ 
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*  V  »  i  ,  k  -,»*»  ii  ,i  .,i  .**  t1*  ^iVr^VreSV 


H  (winopn)  {  /*  window  it  Mill  optn  */ 

goto  da  /*  enter  processing  loop  */ 

> 

•ndx  *  -1;  /*  tot  indtx  out  of  rang*  •/ 

w  -  wn_open(page,  row,  ool,  width,  htight,  ttrib,  bttrib); 
wnjitle^, “CONTROL  PANEL'); 

wn_*yno(w,TRUE);  /*  sync  cursor  •/ 

wpeave  »  w,  /*  tavt  pointer  */ 

If  (w  •  -  NULL)  r«tum(9g);  /*  out  of  mem  or  just  fubar  */ 
winopn  -  TRUE;  /•  say  window  is  open  */ 

1*0;  /*  inlt  indtx  •/ 

whHt(mx->som[l].r)  {  /*  for  as  long  as  wt  have  data  */ 

wn_puta(w,  mx->scm[i].r,  mx->scm[i].c,  mx->scm(il.t); 
i++; 

> 


da 

w  -  wpeave;  /*  restore  pointer  */ 

I  *  Indx;  /*  BLINDLY  assume  that  we're  back  */ 

IfO  <  mx->fm)  i  -  mx->fm;  /*  and  reset  If  Vis  now  out  of  */ 

tf(l  >  mx->lm)  I  *  mx->fm;  /*  range  •  (dumb,  but  it  works)  */ 

while(TRUE)  {  /*  till  we  exK  */ 

wn_!ocats(w,  mx->scm[i].r,  mx->scm(i).c); 


/*  see  whats  goin’  on  •/ 

/*  ESC  (user  wants  out)  -  swk  */ 
/*  swk  RETURN  */ 

/*  dose  window  on  return  strike  ?  */ 
/*  dose  the  window  */ 

/*  say  window  is  dosed  •/ 

/*  remember  last  Indx  */ 

/*  return  with  rv  */ 


o  *  v_getch()  >  >  8; 

H(c  -  -  ESC)  break; 

W(c  -  -  RET)  { 

W(cflag)  { 
wndose(w); 
winopn  -  FALSE; 

> 

Indx  -  I; 

return  (mx->  torn  (l].rv); 

> 

I*(C  *  «  DARROW)  c  *  SPACE;  /*  swk  conversion  */ 

W(c RARROW)  c  «  SPACE;  /*  swk  conversion  */ 

lf(c  -  -  LARROW)  o  •  BS;  /•  swk  conversion  */ 

If  (c  *  -  HARROW)  o  -  BS;  /*  swk  conversion  •/ 

W(o -- SPACE  ||  c -- DEL  1 1  c -- BS)  { 
lf(c  --  SPACE)  /*  foreward  ??  */ 

I++;  /*  bump  Index  */ 

else 

K  /*  decrement  */ 

W(l  <  mx->fm)  I  »  mx->lm;  /•  wrap  on  either  */ 

WO  >  mx->lm)  I  -  mx->fm;  /*  end  */ 


> 


/*  endW  */ 

/*  end  while  */ 
-  FALSE) 


> 


W  (silentflg 

{ 

snd_oonflrmO; 


wn_doee(w); 
-FALSE; 
return  (90); 


/•bye  bye*/ 

/*  say  window  is  dosed  •/ 
/•  nothing  selected  •/ 


106 


•J  V  A  A  A  Su  * 
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>» 
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/• - */ 

/*  Open  window  FOR  LOGO 


void  disp  logoO 

{ 

wl  -  wn_open(0,3,5,65,5,Cyn_Blk,Red_Yel); 
w2  «  wn_open  (0,15, 15,36, 5, Cyn_Blk,Red_Yei); 

wn_pot*(w1  AS,"  Welcome  to  the  ORACLE...*); 
wn_put*(w2,0,5,'  Rollln  JLuti  *); 
wn_puta(w2,2, 1 0, "Version  4.5*); 
if  (silent  flfl  -  -  FALSE) 

{ 

daeaicO; 

> 

wn_put*(w2,4,5,'Pre*»  any  key  to  Begin"); 

vgetchO; 

wn_doee(w1); 

wn  doee(w2); 

> 

/*• - 7 

/*  Setup  Main  acraan  area  */ 

/. - */ 

void  dlspworkO 

{ 

if  (ueerdrtlg  -  -  TRUE) 

{ 

wn_dr(w2); 

wnj>uts(w2, 0,8, ’PLAYERS'); 
wn_dr(w3>; 

wn_puta(w3, 0,20, "PREFERENCE  VECTORS"); 
wn_dr(w4); 

wn_puta(w4,0, 1 5, "COMMAND  AREA"); 

>  ’ 

elae 

{ 

wl  -  wn_open(0, 0,5,65,1  ,Cyn_Blk,Red_Yei);  /*  titia  window  at  top  */ 
wn_puta(wl,0,l5,"  ORACLE"); 

w2  «  wn_opan(1000,4,0,19,17,Blu_Wht,Blu_Blu);  /*  player  window  */ 
wn_puta(w2,0, 8, "PLAYERS"); 

w3  »  wn_opan (1 000,4,20,60, 1 7,Wht_8ik ,Cyn_Wht) ;  /*  vector  window  */ 
wnjHite(w3,0^0,"PREFERENCE  VECTORS'); 

w4  «  wn_open(1 000,22,0,80,3,Cyn_Blk,Cyn_Wht) ;  /*  command  window  */ 
wn  _puta(w4, 0,15, "COMMAND  AREA"); 


> 

> 

/. - ./ 

/*  Inctruction  Screen  •/ 

/* - 7 

void  instruct  0 


{ 

WlNDOWPTRw; 
lntl,J,  k,  doel,doa2; 
long  Wme; 

w  -  wn_open(0,2,9,6O,19,Wht_Blk,Blu_Wht); 

wn_pdntf(w,'  DOS  VER  %d.%d  at%a',_oamajor,_osminor,ctime(&ltime)); 
wn_puts(w,3,1,'  The  ORACLE  It  •  tool  for  the  conflict  analysis'); 
wn_puts(w,4,l,'of  Fraaar  and  Hi  pals  mathod  of  metagame  analysis'); 
wnjHits(w,5,1,'and  is  smart  In  It’s  operation.  Tha  program  *}; 
wn_puts(w, 6,1, -will  only  work  for  two  players  and  a  total  number*); 
wn_puts(w,7,l,*of  8  options  divided  in  any  manner  between  the  *); 
wn_puts(w,8,l , 'players.  The  ORACLE  accepts  the  decimal  vectors'); 
wn  jxrts(w,fl,1,-from  the  operator  and  returns  the  stability  outcome'); 
wn_puts(w,  10,1,  "with  the  Ui's  displayed.  ■); 
if  (silent  fig  -  -  FALSE) 

{ 

andconfirmO; 

> 

wn_puts(w,14,1,'  Press  any  key  when  ready  to  Begin  "); 

vgetchO; 

wn  ck>ee(w); 

} 

/* - 7 

/*  Help  Soreen  */ 

/. - •/ 

void  userhelpO 

{ 

WlNDOWPTRw; 

Inti,),  k,  doal,dos2; 
longHime; 

w  -  wn_open(0, 2,9,60, 19, WhtBlk.BluWht); 

wn_tWe(w,'HELP  SCREEN"); 
time(&ltlme); 

wn _printf(w,“  DOS  VER  %d.%d  at%s',_osmajor,_osminor,ctime(&ltlme)); 
wnjHits(w,2,1. 'CONTROL  COMMANDS;'); 
wn_puta(w,3,3,*  +  Switch  to  binary  input') , 

wn  _puts(w,4,3,*h  Get  popup  control  panel') ; 

wn_puta(w,5,3,T  Set  operation  flag  to  True  value'); 
wn_puts(w,6,3,*F  Set  operation  flag  to  False  value"); 
wn _puts(w,7,3,*-  exit  program  and  quit  from  vector  stage  "); 

wn  puts(w,8,3,'cr  Step  to  next  program  phase '); 
wn _puts(w,9A'&  Logical  AND ->  1&2"); 

wn_puts(w,10,3,*|  Logical  OR ->  1(2'); 
wn_puts(w,11,3,''>  R  arrow  move  right  *); 
wn_put»(w,12,3,'<-  L  arrow  move  left  '); 
wn _puts(w,l3,3,*~  Up  arrow-  Decimal  entry  In  ranking  ’); 

wn_puts(w,  14,3,"V  Down  arrow  -  Binary  entry  in  ranking  "); 
wn _puts(w,17,1,*  Press  any  key  for  next  Page '); 

vgetchO; 

If  (ellent_flg  -  -  FALSE) 

{ 

snd  confirm  0; 

> 


wn_ok(w); 

wn i_puts(w, 0,1, "PAGE  TWO  •  CONTINUED*); 
wn_puts(w,  1.1 /COMMAND  UNE  SWITCHES  FOR  STARTUP"); 
wn _puts(wP3,1,’/e  Call  KES  during  atari"); 
wn_puts{w,4,1,*/f  Bypass  the  opening  screens"); 
wn_puts(w,5,1,7dlag  Call  diagnostic  screen  before  starting*); 
wn_puts(w,6, 1  ,"/s  Silence  the  sounds"); 
wn_puts(w,7,1,"/Vb  filename  Use  a  different  knowledge  base*); 
wn_puts(w, 8,1, "/rank  Display  rank  value  at  bottom  of  ranking"); 
wn_puts(w, 9,1  ."/video  Use  BIOS  instead  of  direct  screen  write"); 
wn_pulsf*.17.1,"  Press  any  key  when  ready  to  Begin  "); 
vgetchQ; 
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H  (silent  fig 

( 


FALSE) 


snd_oonflrmO; 


} 


wn_dose(w); 


> 


/*  Color  Setup  Screen 
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/* 


void  usercolofsO 

{ 

WINDOWPTRw; 

Int  I,  |,  k,  c; 

int  fore- 1,  back -7, Front,  Back; 

static  Int  Fcolor[8]-  (BLACK, RED, GREEN, YELLOW, BLUE.MAGENTA.CYAN, WHITE}; 
static  Int  Bcdor[8]«  (BLACK, RED.GREEN, YELLOW, BLUE, MAGENTA.CYAN, WHITE}; 
w  -  wn  open  (0, 1 0,8,60,8,  Rsd_Wht,Grn_Wht); 
wn_tWe(w."SET  WINDOW  COLORS"); 

wn _puts(w,S,1, "Press  uparrow  or  down  arrow  to  change  Foreground"); 
wn_puts(w,6, 1/Press  left  right  arrows  for  Background’); 
wn_puts(w, 7,1, "Press  return  when  done’); 


wnputsfw, 2,1, "This  sets  the  Player  window"); 
do 
( 

c  -  v  getchO  >  >  8; 
switch  (c) 

( 

case  RET: 

wn_oolor(w2,  Front,  Front) ; 
break; 
iUARROW: 

+  +I; 

fore  -  i%8; 

Front  -  v_setatr(Bcolor(back],Fcolor(fore],0,0); 
wn_natrib(w, Front); 
break; 
i  DAB  ROW: 

-i; 

if  o  <  0) 

i-7; 

fore  -  l%8; 


Front  ■  v_setatr(Bcolor[back],Fcolor[fore],0,0); 
wn_natrib(w, Front); 
break; 
case  RARROW: 

+  +i; 

back  -  j%8; 

Front  »  v_setatr(Bcolor[back],Fcclor[fore],0,0); 
wn_natrib(w,Front); 
break; 
case  LARROW: 

H; 

tf  0  <  o) 

i“7; 

back  «  i%8; 

Front  *  v_setatr(Bcolor[back],Fcolor[fore],0,0); 

wn_natrib(w, Front); 

break; 

default: 

break; 

> 

} 

while  (cl-  RET); 

wn_clr(w); 

wn_puts(w,2,1  ."This  sets  the  Preferance  Vector  window*); 
wn_puts(w,5,1  ."Press  uparrow  or  down  arrow  to  change  Foreground'); 
wn_puts(w,6,1 , 'Press  left  right  arrows  for  Background'); 
wn_puts(w,7, 1  ,'Press  return  when  done'); 
do 
{ 

c  «  v  getchO  >  >  8; 
switch  (c) 

{ 

case  RET: 

wncolor  (w3,  Front,  Front) ; 
break; 
case  UARROW: 

+  +I; 

fore  -  i%8; 

Front  -  v_setatr(Bcolor[back],Fcolor[fore),0,0); 
wn_natrib{w, Front); 
break; 
case  DARROW: 

If  (I  <0) 

1-7; 

fore  «  i%8; 

Front  -  v_setatr(Bcolor[back],Fcolor[fore].0,0); 
wn_natrib(w,  Front); 

break; 
case  RARROW: 

+  +i; 

back  -  j%8; 

Front  «  v_setatr(Bcolor(back],Fcolorlfore],0,0); 
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wnjiatrib  (w,  Front) ; 
break; 
case  LARROW: 

H; 

if  (i  <  0) 

i-7; 

back  =  l%8; 

Back  =  v_8etatr(Bcolor[back],Fcolor[fore],0,0); 

wn_natrib(w,  Front); 

break; 

default: 

break; 

} 

} 

while  (c!=  RET); 

wn_clr(w); 

wn_puts(w, 2,1, "This  sets  the  Command  window"); 
wn_puts(w, 5,1, "Press  uparrow  or  down  arrow  to  change  Foreground"); 
wn_puts(w, 6,1, "Press  left  right  arrows  for  Background"); 
wn_put8(w,7,1,“Press  return  when  done"); 
do 
{ 

c  =  v  getchO  >  >  8; 
switch  (c) 

{ 

case  RET: 

wn_color(w4, Front, Front); 
break; 
case  U ARROW: 

+  +i; 

fore  =  i%8; 

Front  »  v_setatr(Bcolor[back],Fcolor[fore],0,0); 
wn_natrlb  (w,  Front) ; 
break; 
case  DARROW: 

-i; 

if  (I  <  0) 

1=7; 

fore  =  i%8; 

Front  =  v_setatr(Bcolor[back],Fcolor[fore],0,0); 
wn_natrib  (w, Front) ; 
break; 
case  RARROW: 

+  +ii 

back  =  j%8; 

Front  =  v_setatr(Bcolor[back],Fcolor[fore],0,0); 
wn_natrib  (w,  Front) ; 

break; 
case  LARROW: 

Hi 

if  (j  <  0) 

J  =  7; 

back  =  l%8; 
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Front  -  v_setatr(Bcolor[back],FColor[forel,0,0); 

wn_natrib(w,Front); 

break; 


default: 


while  (c!«  RET); 


wncfrM: 

wn_puts  (w,5, 1 , "Press  any  key  when  ready  to  Begin*) ; 

vgetchO; 

wn_closa(w); 


/•  Diagnostic  Screen  */ 

/* - 7 

void  diagnosticO 

{ 

WINDOWPTR  w ; 
int  i,  J,  k  ; 
long  Itime; 

char  'user  Jst; 

static  char  ok Jst[]  =  {T.'F*}; 
w  -  wn_open(O,2,9,6O,19,Wht_Blk,0lu_Wht); 

~wn_tHle(w, "DIAGNOSTIC  PANEL’); 
time(Altlme); 

wn_printf(W,"  DOS  VER  %d.%d  at  %a’,_osmaior,  oamlnor,ctima(8Jtima)); 
wn_puts(w,3,1, "Program  is  writing  direct  to  memory"); 
if  (wn_dmaflg  »  -  FALSE) 

wn _put*a(w, 3, 45/FALSE*, Red_Yel); 


wn_putsa(w,3,45/  TRUE*,Rad_Yel); 

wn_puts(w,5,1  /Call  Kes  for  expert"); 
if  (exp  flg  »  »  FALSE) 

wn_putsa(w, 5, 45/FALSE*, Red  _Y*I); 

else 

wn_putsa(w,5,45,"  TRUE*,Red_  Yet); 
wn_puts(w,7,1  /Colors  are  default  values'); 
wn_putsa(w,7,45,"  TRUE",Red_Yel); 

wn_puts(w,  10,1 /Direct  Memory  Writes"); 
wn_puts(w,  11,1 /Enter  T,F  or  cr  to  accept”); 
wn_geta(w,user_lst,6,ok_lst); 
switch  (*ueer_lst) 

{ 

case  NULL 

break; 

caseT: 

wn_dmaf1g  »  TRUE; 
wn_putsa(w,3,45/  TRUE",Red_Yel); 
break; 
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eaae’F: 

wn_dmaflg  -  FALSE; 
wn_putsa(w,3, 45, “FALSE”, Red_Yel); 
break; 

default; 

braak; 

> 

wn_delrow(w,12) ; 

wn_delrow(w,11) ; 

wn_delrow(w,10) ; 

wn_put»(w,  10,1, ’Call  Kaa  “); 

wn i_puts(w,1 1,1,’Entar  T,F  or  cr  to  accept”); 

wn_geta(w,user_lst,6,okJst); 

•witch  (*user  1st) 

{ 

case  NULL: 

break; 

case  T: 

exp_flg  «  TRUE; 

wnj)utsa(w,5,45,”  TRUE”,Red_Yel); 
break; 

case  'F: 

expflg  »  FALSE; 

wn_putsa(w,5,45,”FALSE”,Red_Yel); 

break; 

default: 

break; 

> 

wn_delrow(w,12) ; 

wn_delrow(w,11) ; 

wn_delrow(w,10) ; 

wnjMitaflw,  10,1,' "Change  Colors  ”); 

wn  jMits(w,1 1,1, "Enter  T,  or  cr  to  accept  defaults”); 

wn_gets(w,user_lst,6,ok_lst); 

switch  ("user  1st) 

{ 

case  NULL: 

break; 

case  T: 

wn_putsa(w,7,45,”  USER",Red_Yel); 
user_clrflg  =  TRUE; 
user_color80; 
break; 

default: 

break; 

} 

wn_puts(w,14,1,“  Press  any  key  when  ready  to  Begin  "); 
vjjetchO; 

If  (sllentflg  -  -  FALSE) 

{ 

sod  oonfirmO; 

} 

wn  close(w); 

> 


113 


/. - 7 

/*  Convert  decimal  to  binary  vector  */ 

/* - */ 

void  oon2Wn(decimal,tot_num_opt,ord_num,v«c) 

Int  vec[20][236] ; 
char ‘decimal ; 

Int  tot_num_opt,  ord_num ; 

{ 

int  Index  «  1,  dec_number ; 
deenumber  -  atoi  (decimal) ; 
vec[0][ord_num]  -  dee  number ; 

do 

{ 

vec[index][ord_num]  «  dee  number  %  2 ; 

+  -i- index ; 
dec  number /«  2 ; 

> 

while  (Index  <  tot  num  opt  +  1); 

> 

/* - */ 

/*  Convert  binary  vector  to  dec  */ 

/*' - 7 

void  con2dec(tot_num_opt,p1_optlhorz_pos,rowlvec) 

int  totnumopt,  plopt,  horzjsos,  row,  vec(20](256]; 

{ 

Int  power'  1 ,  decimal  -0,  apace,  opt,  blnarybit; 
atatlc  ch  ir  okletQ  «  {'0',T,'\0'}; 
char  •dei  vec,  »ok_point; 
wn_aync(w?.TRUE); 
ok_polnt  -  okiat; 

for  (opt«1,  apace -3;  opt<  -tot  num_opt;  +  +opt) 

{ 

If  (opt>pf_opt) 
apace  -  10  -  p1_opt; 
wn_locate(w3,opt  +  apace.horapoa); 
wn_oeta(w3,dec_vec,6,ok_point); 
binary_bit  -  atoi(dec_vec); 
vec[opt][row]  ■  binary _bit; 
decimal  -  decimal  +  (binary _bit  *  power); 
power  -  power  *  2; 

> 

vec(0][row]  ■  decimal; 
wn_aync(w3, FALSE); 
v  hidecO; 

> 

/• - •/ 

/*  Generate  all  Vectora  7 

/* - 7 

void  Generate(p1_opt,p2_opt,llmlt,  array) 

int  limit,  array [20] [256],  p1_opt,  p2_opt; 


{ 

int  tot_nom_opt,  I,  J,  wjlmit « 15; 
int  ooJumn  .Index,  dec_number; 
int  space; 
char  pm_buf[5]; 

t°t_num_opt  -  plopt  +  p2_opt; 

for  (column  -0;  column  <  limit;  +  ♦  column) 

{ 

array[0][column]  •  column; 
index  -  1; 

dec_number  -  column; 
do 

{ 

array[lndex][oolumn]  -  dee  number  %  2 ; 

+  +  index ; 
dec  number  /«  2 ; 

> 

while  (index  <  tot  num  opt  +  1); 

~  > 

for  (column -0;  column  <  w  limit;  >  +column) 

( 

sprintf(prn_buf,"%d",array[0][column]); 
wnj>utaa(w3, 2, column  *3,pm_buf,Blu_Wht); 
for  (1-1,  space-3 ;  l< -tot  num  opt ;  +  +i) 

{ 

If  0  >  pl_opt) 

{ 

space  »  10 -pi  opt ; 

} 

aprlntf(prn_buf,  "%d",  array[l][column]); 
wn  _puts(w3,i + space, column*3,prn_buf); 

} 

} 

} 

r - v 

/*  Outcome  Removal  */ 

/* - V 

Int  Rsmov_vec(array,result,limlt,p1_opt) 
int  array [20] [256],  limit,  p1_opt; 
char  *result; 

{ 

Int  maak[5][2],how_many,i,  j  .left; 

Int  pos, column,  num  char,  place,  ls_same  ; 
int  newjlmit, where, cnt_ma8k; 
char  oon_buf(25],  *»emp_buf; 

If  ( stmcmp(result,’  unknown", 9)  -  -  0) 

( 

wn_dr(w4); 

wn_puts(w4, 1,5, "unknown  removal"); 
return  (limit); 
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> 

aprtntf(oon_buf,"%a,,,raauft); 

for  (toft- 1, pot  «1,ont  maak-O;  toft  <9;  +  +toft) 

{ 

If  (oon_buf[poa]  “  “  '1') 

{ 

tf  (toft  >  p1_opt) 

< 

whara  «  toft  -  pi  opt; 

> 

•JM 

{ 

whara  »  toft; 

> 

maak[cnt_mask][0]  •  whara; 
maak[cnt_maak](l]  »  1; 
cnt_maak  -  cnt  maak  +  1; 

> 


if  (oon_buf[poa]  -  -  'O') 

{ 

If  (toft  >  pl_opt) 

{ 

whara  «  toft  -  pi  opt; 

> 

atoa 

{ 

whara  «  toft; 

> 

maak[cnt_maak][01  -  whara; 
maak[cnt_mask][l]  ■  0; 
cnt  mask  «  cnt  maak  +  1; 

) 

pot  -  poa  +  2; 

> 

howmany  »  cnt  mack; 

for  (column  -  O.ptooa  -  0;  column  <  limit;  +  +oolumn) 

( 

for  (i-0,la_aama-0;  I  <  howmany;  +  +1) 

1 

If  (array[maak[i)[0]][column)  -  -  mask[i][l]) 
+  +  to_aama; 

> 

H  (ia_»ama  | .  howmany ) 

{ 

tor  Q  •  0;  j<  15;  ♦ +|) 

{ 


) 


array [j][placa]  -  array[j][column); 


return  (place); 


/* - */ 

/*  Display  Current  outcomes  */ 

r - v 

void  New_out(pl_opt,p2_opt, limit, array) 

int  limit,  array[20][2S6],  pl  opt,  p2_opt; 

{ 

Int  tot_num_opt,  I,  J,  w  JlmK; 
int  oolumn  .index,  daenumbar; 
int  space; 
char  pm_buf[5]; 

tot  num  opt  »  pl_opt  +  p2_opt; 


wlfmft  »  limit; 
if  (limit  >  16) 

( 


w  limit  -  16; 


wn_dr(w3); 

for  (column -0;  column  <  w  limit;  +  +  column) 


sprintf(prn_buf,‘%d',array[0][columnJ); 
wn_put8a(w3, 2, column  *3,pm_buf,Blu_Wht); 
for  (i«1,  space -3 ;  l<  »tot_num_opt ;  +  +i) 


If  (I  >  pi  opt) 


space  »  10  -  p1_opt ; 


sprintf(prn_buf,  "%d’,  array[i][column]); 
wn_puts(w3,l + space,  oolumn*3,prn_buf); 

} 

H  (sort_flfl  -  -  TRUE) 

( 

sprintf(pm_buf,  ”%d",  array(19][column)); 
wn_puts(w3, 16,  column  *3,prn_buf); 

}  " 

> 


/*  Find  same  vector  in  2  */ 

/* - 7 

void  Find_same(Prefvec_1,Prefvec_2,same_vec,len_vec1,  Ian_vec2) 

Int  Prsfvec_1[20][256J,  Prefvec_2(20][256],  sams_vsc(256] ; 
int  lenvecl ,  Ien_vec2; 

{ 

Int  hon_pos  *  0,  samepos  »  0 ; 


for  (horz_pos«0;  hoapos  <  Isnvecl;  +  +horz_pos) 

{ 

same_vec[horz_pot]  -  -1;  /*  if  no  matching  vac  than  -1  */ 


- 

' 


for  (*ama_pos  -  0;  sama_pr'*<len_vac2;  +  +  »ama_po») 

{ 

H  (PrefvecJ  [0][hof2_pot]  -  -  Prefvec_2[0][same_pos]) 

{ 

(amavacfhorzpot]  -  samejjot; 
brack; 

} 

> 

> 

} 

/* - v 

/*  Find  the  Ul‘*  */ 

/*• - 7 

void  stabta  (start,  quit,  ord_num,  vac) 
int  atart,  quit,  «d  num  ,  vec[20][256] ; 

{ 

int  issama ,  oolumn  ,  row ,  ul- 10,  ha*_ui »  9 ; 
int  oount-0 ; 

vec[has_ul][ord_num]  -  0;  /•  rasat  number  ui’t  to  zero  */ 

tor  (column  «0 ;  oolumn  <ord_num  ;  +  +  column) 

i 

Issama  -  o ; 

ter  (row -start ;  row<  -quit ;  +  +row ) 

{ 

laaama  -  Issama  +  abs(vas[row][coiumn]  -  vec[row][ord_num]) ; 

> 

if  (la  aama  -  -  0 ) 

{ 

vac  [count +ui][ord_num]  -  vec[0][column] ; 

♦  + count ; 

vac[has_ul][ord_num]  -  oount; 

> 

> 

> 

r - v 

/*  Sotva  Function  tor  r.u.a  •/ 

r - 7 

void  eolve(lan_vecl,len_vec2,vecl,vec2,ans1,ans2) 
int  Ian_vae1  ,lan_vac2,  vac  1  [20] [256],  vac2[20][256] ; 
char  anal  [296],  ans2[256] ; 

< 

int  row,  ui  -  S,  depth,  depth2,  ord  num  •  0 ; 

Int  notaanctionad  -  FALSE, piaoa.matchvac  -  FALSE; 

Int  oommon  ul  -  FALSE; 

tor  (row-0  ;  row<len_vec1;  +  -trow)  /*  step  through  vector  */ 

{ 

If  fvec1[ui](row]  -  -  0) 

anal  [row]  -  V;  /*  if  no 

ui  than  rational*/ 


not_sanctioned  -  FALSE;  /•  reset  flag  */ 
for  (depth-ui;  depth<vec1[ui][row]+ui;  +  +depth) 


/•vecl  ui's  */ 


/*  chock  each  ui  in  play  A  */ 


*  find  ui  in  piay2  •/ 


match_vec  -  FALSE; 

for  (placa « 0;  placa < Ian_vac2;  +  +  place) /‘check  in  play2  vecs  */ 

{ 

if  (vecl  [depth  +  1][row]  »  -  vec2[0] [place])  / 


match_vec  =  TRUE; 
break; 


lf((match_vec  -  »  FALSE)  1 1  (vec2[ui][place]  -  «  0)) 
not  aanctloned  •  TRUE; 


common  ui  -  FALSE; 


/*  reset  flag  for 


common  vectors  */ 


ui  In  a*/ 


H  ((matchvec  -  -  TRUE)  &&  (row  >  ordnum)) 
preferred  */ 


for  (depth2-ui;  depth2 < vec2[ui] [place] + ui;  +  +depth2) 

{ 

match_vec  -  FALSE; 

for  (ord_num«0;  ord_num < len_vec  1 ;  +  +ord_num)  /‘find  b's 


if  (vec2[depth2+1][place]  »«  vecl  [0][ord_num]) 

{ 

match  vec  -  TRUE; 
oommon  ui  -  TRUE; 
break; 

} 

} 

/*  is  ui  more 


no  ui  */ 


not_sanctioned  «  TRUE;  /*  if  yea  then  not  sanctioned  */ 
if  (commonjjl  ■  «  FALSE) 

not_sanctioned  -  TRUE;  /*  if  no  common  ui  then  same  as 


If  (not_sanctioned  »  •  TRUE) 
ansi  [row]  «  'u'; 

ansi  [row]  »  's'; 


for  (row-0 ;  row < Ien_vec2;  +  +row) 

{ 

if  (vec2[ui][row]  -  -  0) 
ans2[row]  -  Y; 
ui  then  rational*/ 


/*  step  through  vector  •/ 


/*  if  no 


{ 


notsenctioned  »  FALSE; 

for  (depth  «ui;  depth  <  vec2[ul][row] + ui;  +  +  depth)  /*  check  ui  in  A  */ 


ord  num  «  0; 


for  (piece  >0;  piece  clenvecl;  +  +  piece) 

{ 

if  (vec2[depth  +  1][row]  -  -  vecl  [0][plece]) 

{ 

metch_vec  »  TRUE; 
breek; 

> 

> 

if((metch_vec  «  »  FALSE)  | )  (vec  1  [ui] [piece]  «  »  0)) 
noteenctioned  «  TRUE; 

else 

{ 

common_ui  -  FALSE; 

for  (depth2«ui;  depth2<vec1[ul][plece]+ui;  +  +depth2) 

{ 

metchvec  -  FALSE; 

for  (ord_num«0;  ord_num<len_vec2;  +  +ord_num) 


/•find  b's 


ui  in  e*/ 


{ 


if  (vec1[depth2+  1][plece]  -  -  vec2[0][ord_num]) 

{ 

metch  vec  »  TRUE; 
oommon_ui  -  TRUE; 
breek; 

> 

> 


if  ((metch  vec  »  »  TRUE)  &&  (row  >  ord  num)) 

not  eenctioned  »  TRUE; 


if  (oommon_ui  •  «  FALSE) 

not  eenctioned  »  TRUE; 

> 


} 


if  (not_*enctioned  ■  »  TRUE) 
ene2[row]  •  'u'; 


ene2[row]  •  's'; 


} 


/*- 


/*  Simutteneoue  Senctton 
/• - 


V 


-7 


void  timul  eenct(len_vecl,len_vec2,ent1,ene2,eeme_vec,Prefvec_1,Prefvec_2) 
Int  eeme_vec[258],Prefvec_1(20][256],Prefvec_2[20][256]; 

Int  Ien_vec1 ,  Ien_vec2; 
cher  enel  [2S6),ene2[256], 


{ 
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1  -v  v  v  '•*  v 


fnt  hon_poe,eum_vec, place, f.j,not_sanctioned =0; 
lot  ord_num,  found  it; 

for  (bora _pot«0;  horz  pot<ien_vecl;  +  +  horz  pot)  /*  vac  in  play  A  */ 

{ 

H  (tame_vec[hoa_poa] 1-  -1) 

{ 

place  «  tame_vec[hor7_pos); 

If  (ane1[hora_poa]  -  -  V  &&  an*2[place]  -  -  •u1) 

{ 

not_tanctioned  -  FALSE; 

for  (i“  10;  i<(10  +  Prefvec  1[9][horz  pot]);  +  +1) 

{ 

for  Q  — 10;  j<(10+Prefvec  2[9][place]);  + +]) 

{ 

tum_vec  -  Prefvec_ip][horz_poa]+Prefvec_2[j]lplace] ; 
tum_vec  «  tum_vtc  -  Prefvecl  [0][horz_pos); 
found_lt  -  FALSE; 

for  (ord_num»0;  ord_num<ltn_vtc1;  +  +ord_num) 

{ 

If  (sum  vec  »  »  Prefvecl  [0]Iord_num]) 

{ 

foundlt  -  TRUE; 
brtak; 

} 

> 

H  ((found  Jt  •  *  TRUE)  &&  (horz_pot>  ord  num)) 
notaanctioned  *  TRUE; 

} 

} 

if  (nottanctioned  -  -  FALSE) 
anal  [hora_poa]  »  'S’; 

notaanctioned  -  FALSE; 

for  (1-10;  i<(10+Prefvec_2[9]lplaceJ);  +  +1) 

{ 

for  (j-10;  j<(10+Pr*fv*c  1(9][horz  pot]);  ++]) 

{ 

tum_v*c  -  Prefvec_1[j][horz_poe]  +  Prefvec_2[i][place] ; 
aum_vec  -  tum_vac  -  Prefvec_2[0][place]; 
found _tt  -  FALSE; 

for  (ord_num»0;  ord  num  <  Ien_vec2;  ++ord_num) 

{ 

H  (tum_vtc  -  ■  Prefvec_2(0][ord_num]) 

( 

found_it  -  TRUE; 
break; 

) 

} 

if  ((found  Jt  -  -  TRUE)  &&  (horr_pos>  o rd_num)) 
not_tanctioned  «  TRUE; 

} 

} 

If  (notaanctioned  -  »  FALSE) 

•nt2[place]  -  'S'; 


> 


> 

> 

> 

/. - 7 

/*  Equilibrium  */ 

/. - V 


void  equilibrium  (len_vec  1  .anal  ,ans2,Ans,vec1  ,vec2,same_vec) 

Int  Ien_vee1 ; 

char  anal  [256],  ans2[256],  Ans[256] ; 
int  vacl  [20]  [256],  vec2[20][256],  same_vsc[256] ; 

{ 

int  stop,  place; 

for  (step-0;  step<len_vec1;  +  4- step) 

{ 

if  (same_vec[step]  l«  -1) 

{ 

place  «  same_vec[step]; 

if  (((ansi  [step]  «  -  V)|  |  (ansi  [step]  -  -  's')  1 1  (ansi  [step]  -  -  'S'))  && 

((ans2[place]  -  -  V)  1 1  (ans2[place]  -  -  's')  1 1  (ans2[place]  -  -  'S')) ) 
Ansfstep]  «  'E'; 

else 

Ans[step]  -  'x'; 

} 

else 

{ 

if  ((ansi  [step]  «  «'r')  1 1  (ansi  [step]  «  *  's')  1 1  (ansi  [step]  «  »  'S')) 

Ans[step]  -  'E'; 

else 

Ans[step]  »  Y; 

} 

} 

> 

/. - •/ 

/*  Set  up  the  final  stability  */ 

/*• - 7 

void  fin_table(len_vec1,len_vec2,an$l,ans2,An8,Prefvec_1,Prefvec_2) 

Int  lenvecl  ,ien_vec2; 
char  ansi  [256],  ans2[256],  Ans[256] ; 
int  Prefvec_1[20][256],  Prefvec_2[20][256] ; 

{ 

int  i,  row,  J,  hora_pos ; 
int  ui_deep,  pwl; 

char  pt_ane1[2],  pt_ans2[2],  dec_vec[5] ; 


wn_clr(w3); 

wn_puts(w3, 0,20, "STABILITY  TABLE"); 
horapos  -  0; 

If  (!en_vec1  >  Ien_vec2) 
row  «  Ien_vec1; 

else 
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row  -  ton  vec 2; 


tor (j— 0 ;  j  <  row;  ++j) 

{ 

horz_pos  »  horzpos  %  45; 
tf  ((hora_pos  -  -  0)  &&  0  !-  0) ) 

{ 

wn_clr(w4); 

wn_puts(w4,2,lO,"Prest  any  key  for  next  page  ‘); 

wn_gets(w4,dec_vec,4,0); 

if  (*dec_vec  =  *  V ) 

pwl  -  popup{0,5,5,33,14,Yel_Grn,Grn_Wht,&popinfo,FALSE)  ; 
wn_clr(w3); 

wn_puts(w3, 0,20, ‘STABILITY  TABLE"); 

> 

If  <  len_vecl) 

{ 

sprintf  (pt_an*1  ,*%c‘,Ans[j]); 

wn_putsa(w3,1,horz_pos,pt_ans1,Grn_Blk);  /*  Equilibrium  */ 

sprintf (pt  anal,  “%c‘,  ansl[j]); 

wn  j>utsa(w3,2,hor2_pos,pt_ans1  ,Red_Wht); 

sprlntf(dec_vec,  ‘%d“,  Prefvec_1[0][j]);  /'decimal  vector  */ 
wn_putsa(w3,3,horz_pos,dec_vec,Blu_Wht); 

If  (Prefvec_l[9][j]  <  4) 

uideep  «  Prefvec_1[9)[j]  +  10; 

else 

ui  deep  »  14; 

for(i«10;i  <  ui  deep;  ++I)  /•putupui’s  */ 

{ 

sprintf (dec_vec,  ‘%d‘,  Prefvec_1[i]D]); 
wn_puts(w3,i-€,horz  pos.dec  vec); 

} 

> 

if  (j  <  Ien_vec2) 

{ 

sprintf(pt_ans2,  ‘%c‘,  ans2[j]);  /•  r,s,  or  u  */ 

wn_put8a(w3,8,hoi7_pos,pt_ans2,Red_Wht); 

sprintf(dec_vec,  "%d‘,  Prefvec_2(O]0]);  /*  decimal  vector  •/ 
wn_putsa(w3,9,horz_po8,dec_vec,Blu_Wht); 


if  (Prefvec_2[9](jJ  <  4) 

uf_deep  »  Pre/*r*c_2(9][j]  +  10; 

else 

u!_deep  =  14; 

for  (1- 10 ;  I  <  ui  deep  ;  +  +1 )  /*  ui  s  */ 

{ 

sprintf(dec_vec,  “%d\  Prefvec_2[i][j]); 
wn_puts(w3,l  +  1,hoa  pos.dec  vec); 

> 
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SfiJ 


} 

horajjos  «  horz_pos  +  3; 

> 

} 

r - v 

/*  REview  the  Ui  Procedure  */ 

/* - 7 

void  uireviewflenvecl  ,len_vec2,ans1  ,ans2,Ans,Prefvec_1  ,Prefvec_2) 
int  Ien_vec1,len_vec2; 
char  ansi  [256],  ans2[256],  An s [256] ; 
int  Prefvec_1  [20]  [256],  Prefvec  2[20][256] ; 

{ 

Int  i,  row,  j,  horz_pos ; 
int  ui_deep,  pwl; 

char  ptansl  [2],  pt_ans2[2],  dec_vec[5] ; 
wn_clr(w3); 

wn_puts  (w3,0,20,"ST ABIUTY  TABLE'); 

wn_putsa(w3, 0,45, "Player  1“,Red_Yel); 
horapos  *  0; 
row  -  Ien_vec1; 

for  0 = 0 ;  j  <  row;  ++]) 

{ 

horz  pos  *  horz  pos  %  45; 
it  ((horz_po8  =  =  0)  &&  (j  1=  0) ) 

{ 

wn_clr(w4); 

wn_puts(w4,2, 10, "Press  any  key  for  next  page "); 
wn_gets(w4,dec_vec,4,0); 

H  (’decvec  =  «  'h' ) 

pwl  «  popup(0,5,5,33,14,Yel_Grn,Gm_Wht,&popinfo,FALSE) ; 
wn_clr(w3); 

wn_puts(w3, 0,20, "STABILITY  TABLE’); 

> 

sprlntf(pt_ans1  ,"%c",Ans[J]); 

wn_putsa(w3,1,hont_pos,pt_ans1,Grn_Blk);  /*  Equilibrium  */ 

sprintf(pt_ans1,  "%c",  ans1[j]); 

wn_putsa(w3,2,horz_pos,pt_ans1,Red_Wht); 

sprlntf(dec_vec,  "%d",  Prefvec_1[0][j]);  /’decimal  vector  */ 
wn_putsa(w3,3,hora_pos,dec_vec,Blu_Wht); 

If  (Prefvec_1  [9][j]  <  10) 

ui_d  eep  =  Prefvec_1[9][j]  +  10; 

else 

ui_deep  =  20; 

for  (1*10;  i  <  ui_deep  ;  +  +  i )  /*  put  up  ui's  */ 

{ 

sprintf(dec_vec,  *%d",  Prefvec_1[i][j]); 
wn_puts(w3,l-6,hon_pos,dec_vec); 

} 

horz_pos  =  horz_pos  +  3; 
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wn_dr(w4); 

wn_puts(w4,2,10,"Press  any  key  for  Player  2”); 
v_getchO; 
wn_dr(w3); 

wn_puts(w3, 0,20, ’STABILITY  TABLE"); 

wn_putsa(w3, 0,45, ’Player  2",Red_Yel); 
horzpos  =  0; 
row  =  Ien_vec2; 

for  (j=0 ;  j  <  row ;  +  +j ) 

{ 

horz_pos  =  horz_pos  %  45; 
if  ((horz  pos  =  =  0)  &&  (j !  =  0) ) 

~  ( 

wn_clr(w4); 

wn_puts(w4,2,10,’Press  any  key  for  next  page  ’); 

wn_gets(w4,dec_vec,4,0); 

if  (*dec_vec  =  =  ’h‘ ) 

pwl  =  popup(0,5,5,33,14,Yel_Grn,Grn_Wht,&popinfo,FALSE) ; 
wn_clr(w3); 

wn_puts(w3, 0,20, "STABILITY  TABLE"); 

> 

sprintf  (pt_an8l  ,“%c",Ans[j]); 

wn_putsa(w3,1,horz_pos,pt_ans1,Grn_Blk);  /‘Equilibrium  */ 

sprintf  (ptansl,  "%c",  ans2[j]); 

wn_putsa(w3,2,horz_pas,pf_ans  f  ,Red_VVht); 

sprintf(dec_vec,  "%d",  Prefvec_2[0][j]);  /*  decimal  vector  */ 
wn_putsa(w3,3,horz_pos,dec_vec,BluWht); 

if  (Prefvec_2[9)[j]  <  10) 

ui_deep  =  Prefvec_2[9][j]  +  10; 

else 

ui_deep  =  20; 

for  (i  =  1 0  ;  i  <  ui_deep  ;  +  +i )  /‘putupui’s  */ 

{ 

sprintf(dec_vec,  "%d",  Prefvec_1[i][j]); 
wn_puts(w3,i-6,horz_pos,dec_vec); 

} 

horz_pos  =  horz_pos  +  3; 

} 

> 

/* - V 

/*  Alter  the  ordering  of  decimal  vectors  */ 

r - 7 

void  alter_vec(array,limit,player,p1_opt,p2_opt) 
int  array[20][256],  limit,  p1_opt,p2_opt; 
char  ‘player; 

int  cursor_po8 = 0,horz_pos = 0, column  =  0,i,j,k,num_opt; 


{ 


int  page  —1  .place, space, nextpage, quit; 
char  #,*pm  but ,*pnl_in; 
unsigned  c,d; 

static  char  ok4Jst(]»  {’O'.'l  7273747576', 778797 +’,’\0'}; 


numopt  *  p1_opt  +  p2_opt; 
quit  -  FALSE;  ~ 


wn_clr(w3); 

wn_puts(w3, 0,20, "Preference  Vectors"); 
sprintf(prn_buf,"%s", player); 
wn_putsa(w3,0,50,pm_buf,Red_Yel); 


for  (column  >0;  column  <  limit;  +  +  column)  */ 
while  (quit  *  =  FALSE) 


horz  _pos  =  hora_pos  %  45; 


if  (((horz_pos  *=  =  0)  &&  (column  !  =  0))  1 1  (column  >  «  limit )) 

{ 

+  +page; 
wn_dr(w4); 

wn_put8(w4,1,5,"Use  <->  ARROW  keys-move  to  outcome,"); 

wn_puts(w4,2,5,“Enter  UPARROW-Decimal  DARROW-Binary-Cr  to  stop  "); 
if  (silent_flg  -  »  FALSE) 

{ 

sndconfirmO; 

> 

wnjocate  (w3,2,horz_pos ) ; 
wn_fixcsr(w3); 
wn_sync(w3,TRUE); 
nextpage  »  FALSE; 


while  (next  page  =»  *  FALSE) 

{ 

c»v_getch()  >  >8; 
wn_locate  (w3,2,horz_pos); 
switch  (c ) 

{ 

case  RET: 

next_page  *  TRUE; 
quit  =  TRUE; 
break; 


case  DARROW: 

wn_putsa(w3,2,horz_pos,"  ",Red_Yel); 
wn_locate  (w3,2,horz_pos) ; 
place  *  (page  *  15)  +  (horz_pos  /  3); 
con2dec(num_opt,p1_opt,horz_pos,  place, array); 
wn_puts(w3,2,horz_pos,"  "); 
wn_locate  (w3,2,horz_pos) ; 
sprintf(pm_buf,  "%d",  array[0](place]); 

wn_putsa(w3,2,horz_pos,prn_buf,Blu_Wht); 
wnjocate  (w3, 2, hori  pos); 


wnjixcsr(w3); 

wn_sync(w3,TRUE); 

break; 


case  RARROW: 

if  (((horz_po8  +  3)  >  «  45)  &&  (column  <  =  limit)) 


{ 

next_page  «  TRUE; 
horz_pos  -  0; 
break; 

} 

if  (horz_pos  -  -  45) 

{ 

wnjocate  (w3,2,horz_pos) ; 
break; 

> 

horz_pos  =  horz_po8  +  3; 
wnjocate  (w3, 2, horz_pos); 
break; 

case  LARROW: 

if  ((horz  pos  -  «  0)  &&  (page  >  0)) 

{ 

nextpage  =TRUE; 
horz_pos=0; 
page  -  (page  -  2); 
column  -  (page+1)  *  15; 
break; 

} 

if  ( horz  pos  »  «  0) 

{ 

wnjocate  (w3,2,horz_pos) ; 
break; 

} 

horz_po8  =  horz  pos  -  3; 
wn_locate  (w3,2,horz_pos); 
break; 

case  UARROW: 

place  -  (page  *  15)  +  (horz_pos  /  3); 

wn_putsa(w3,2,horz_pos,“  ’,Red_Yel); 
wn_locate  (w3,2,horz_pos) ; 
wn_gets  (w3,prn_buf  ,2,0) ; 
con2bin(prn_buf,num_opt, place, array); 
wn_puts(w3,2,horz_pos,“  "); 
wnjocate  (w3,2,horz_pos); 
sprintf(prn_buf,  "%d",  array[0]  [place]); 

wn_putsa  (w3,2,  horz_pos,prn_buf  ,Blu_Wht) ; 
for  0  =  1,  space  =  3  ;  i<  =num_opt ;  +  +i) 

{ 

If  (i  >  pl_opt) 
space  >  10 -pi  opt ; 
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«printf(pm_buf,  “%d",  array  [i][plsc*]); 
wn  _puta(w3,i+apac#,horz  jioa.pfnJjuf); 

> 

wnlocate  (w3,2,horz  _pos) ; 
break; 

default: 

next_page  »  TRUE; 
quit  «  TRUE; 
break; 

>  /*  end  of  twitch  ttatement  */ 

>  /*  end  of  while  loop  */ 

wn_sync(w3,  FALSE); 

v_hldecO; 

}  /*  end  of  if  ttatement  for  page  */ 

if  (quit  -  -  TRUE) 

{ 

wn_clr(w3); 

break; 

> 

if  (hore  pos  »  «  0) 

{ 

wn_clr(w3); 

wn_puts(w3,0,20,' 'Preference  Vectors'); 
sprintf(prn_buf,"%s", player); 
wn_putsa(w3,0,50,prn_buf,Red_Yel); 

> 

*printf(prn_buf,‘%d",array(OJ(columnJ); 

wn_putsa(w3,2,horz_pot,prn_buf,Blu_Wht); 

for(l-1,tpace»3;l<»num_opt;  ++i) 

{ 

If  (I  >  p1_opt) 

{ 

apace  -  10-p1_opt; 

> 

aprintf(prn_buf,  "%d',  array[i][column]); 
wn_puta(w3,i + space, hoa_po8,prn_buf); 

> 

hoa  pos  »  hon  pot  +  3; 

+  +column; 

} 

} 

/*• - V 

/*  The  following  routine  it  called  when  KES  would  generate  a  message  that 
would  appear  on  the  terminal  in  standalone  KES,  for  example,  error 
messages,  or  display  commands.  In  this  case,  the  routine  simply  prints  the 
message  and  message  class,  and  returns.  Note  that  no  messages  are  expected 
to  be  generated  by  this  particular  application. 

V 

/* - V 


void  KES_receive_mesg(  text  string,  text  class  ) 
char  *text_string;  /*  The  message  from  KES  */ 

KES  msg  class  type  text  data;  /*  Message  classification  */ 


If  (kes_wn_open  -  -  FALSE) 

w6  »  wn_open  (0,7,5,60, 1 5,Red  JMit,Grn_Wht); 
kes_wn_open  ■  TRUE; 
must_doee_ft «  TRUE; 

•witch  (text_dass) 

cam  KES_exec_err_c: 

wn_prtntf(w6,’KES  System  error:  \n%s“,  text_*tring); 
break; 

case  KES_exec_state_c: 

wn_printf(w6,"KES  System  status:  \n%s",  text_string); 
break; 

case  KESdisplayc: 

wn_printf(w6,’KES  Command  display:  \n%s“,  text  string); 
break; 

case  KEShelpc: 

wn_printf(w6,'KES  Command  help:  \n%s",  text  string); 
break; 

case  KESexplainc: 

wn _printf(w6,"KES  Command  explain:  \n%s",  text_string); 
break; 

case  KES Justify _c: 

wn_printf(w6,”KES  Command  justify:  \n%s",  text  string); 
break; 

case  KES_me8sage_c: 

wn_prlntf(w6,"KES  Command  output:  \n%s",  text_string); 

break; 

default: 

wn_printf(w6,*Unknown  KES  message  code:  \n%s\  text  string); 
break; 

wn_printf(w6,"Press  any  key  to  continue  \n*); 

vgetchO; 

wn_dr(w6); 

If  (must  close  lt  -  -  TRUE) 

{ 

wn_dose(w6); 

kes_wn_open  ■  FALSE; 
must  close  it  °  FALSE; 


This  routine  Is  called  by  KES  only  when  the  value  of  an  undetermined 
attribute  Is  needed.  In  this  case  it  simply  displays  the  same  message 
KES  would  ask  for  the  value  of  the  attribute,  gets  a  response  from  the 
user,  and  returns  the  input  string  as  the  value  of  the  function.  The 
returned  string  must  be  persistent  across  the  function  call,  it 
must  either  be  malloc’ed  space,  or  be  declared  as  a  static  variable. 
Note  that  this  routine  does  not  get  called  in  this  application,  because 
all  of  the  needed  attributes  are  either  inferred  in  the  knowledge  base, 


,V«  i 


iY»V;i 
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or  are  supplied  values  from  the  main  program. 

7 

/*• - 7 

char  »KES_givejralue_str(attribute_deacriptor) 

KES  atr  typa  attribute  dated ptor; 

{ 

static  char  input_llne[STRINGSlZE];  /*  Rasponsa  from  tha  utar  */ 
char  ‘prompt;  /»  Prompt  for  tha  naaded  atr  */ 

H  (kes_wn_open  -  -  FALSE) 

{ 

wn_dr(w4); 

wn_dr(w3); 

kaswnopan  «  TRUE; 
must_dose_it «  TRUE; 
wn_sync(w3,TRUE); 
wn_wrap(w3,TRUE); 

> 

input _line[0]  »  *\0';  /•  Start  with  a  clean  string  */ 

prompt  ■  KES_g_askfor_prompt(  attributa  dascriptor ); 
wn_printf(w3, “Attribute:  \n%s“,  prompt ); 
ffiush(  stdout );  /*  Keep  cursor  on  same  line  as  prompt  */ 

wn_gets(w3,  input _lina,1 .0); 

inputjina[strian(input_lina)]  «  ’\0’;  /*  Remove  tha  trailing  nawlina  */ 
free  (prompt);  /*  Since  KES_g_askfor_promptO  malloc's  storage  */ 
If  (must  closa  lt  -  -  TRUE) 

{ 

wn_sync(w3,FALSE); 

vhidacO; 

wn_d-(w3); 

kas  wn  opan  »  FALSE; 
mustdosaH  »  FALSE; 

} 

return  (Input Jine); 

> 

/• - V 

r - v 

/* 

This  routine  is  called  by  KES  only  whan  tha  members  of  an  undetermined 
class  are  needed.  In  this  case  It  simply  displays  the  same  message 
KES  would  ask  for  the  members  of  the  Class.  Like  KES  give  value  strO, 
this  routine  is  not  called  in  this  application,  since  user-defined  classes 
are  not  used  in  the  knowledge  base. 

V 

r - 7 

char  *KES_g_members(  dassname ) 
char  ‘dass  name; 

{ 

static  char  input _line[STRINGSIZEJ;  /*  Response  from  the  user 
char  ‘prompt;  /*  Prompt  for  the  needed  members  */ 

If  (kas  wn  opan  ■  -  FALSE) 

w6  -  wn_open(0,7,5,60,15,Red_Wht,Grn_Wht); 


{ 


kas_wn_opan  «  TRUE; 
must_dosaJt  -TRUE; 
wn_tync(w«,TRUE); 

wn  wrap(w6,TRUE); 

> 

/*  Prompt  tha  umt  tor  too  naadad  mamb art  •/ 

input  llna[0]  «  ’\0’;  /•  Start  with  a  daan  string  */ 

prompt  -  KES_g_prompt_dass(  daasnama ); 
wn_printf(w6, 'Class  Input:  \n%s",  prompt); 
fflush(  atdout );  /*  Kaap  cursor  on  sama  lina  as  prompt  */ 

/*  Gat  tha  usar's  rasponsa  */ 

/*  fgats(  input Jina,  sizaof(Input_lina),  stdin  );*/ 
wn_gats(w6,input_llne,1 ,0); 

input  lina[strtan(input Jina)]  »  ’\0';  /*  Ramova  tha  trailing  nawlina  */ 
fraa  (prompt);  /*  Sinea  KES_g_prompt_classO  malloc's  storaga  */ 

if  (must  dosajt  «  »  TRUE) 

{ 

wn_sync(w8, FALSE); 
vhidacO; 

wn_dr(w6); 

wn_doaa(w6); 
kaswnopan  -  FALSE; 
must  dosa  it-  FALSE; 

> 

ratum  (input Jina); 


I*  Sort  tha  outcomas  into  vactor  */ 

/*• - 7 

void  Sort  out (array .rank .limit, pi  opt) 

int  array  [20]  [256]  .llmii.p  1  _opt ; 
ohar  *rank[4]; 

{ 

Int  vai.kay; 

Int  ij.k.p; 

Int  tamp_array[20]; 
int  mask_array[4][2], 
tor  (i»  1;  l<4;  +  +I) 

{ 

H  (strcmp(rank[i],'  unknown') !«  0) 

{ 

kay  -  atoi(rank[l]); 
if  (kay  <  0) 

{ 

mask_array[i][1]  -  0; 

} 

alsa 

mask  array[i][1]  «  1; 


> 


key  «  abs(key); 

If  (key  >  pi  opt) 

{ 

key  -  key  -  (4  -  pi  opt); 

} 

maak_arrayp][0]  “  absfkey); 


/*  adjust  for  less  than  4  options  by  first  player  */ 


/*  puts  relative  sort  value  in  19  row  */ 


> 

for  p«0;  Ullmlt;  ++i) 

{ 

array[l9]pj  -  SO; 
for  (p>l;  p<4;  +  +p) 

{ 

If  (array[mask_array[p][0])[i]  -  =  mask_array[p][l]) 

{ 

arrayt19][il  -  array[19]p]  -  ((5  -  p)*(5  -  p)); 

> 

} 

> 

for  (I « 1 ;  I  <  limit;  +  + 1)  /•  start  to  move  arrays  into  order  */ 

{ 

for  (k-0;  k<20;  ++k) 

{ 

temp_array[k]  «  array [k][i]; 

} 

i  -M; 

while ( fl  >  =  0)  &&  (temp  array[19]  <  array[19]p]) ) 

{ 

for  (k=0;  k<20;  +  +k) 

{ 

*rray[k]p  + 1)  =  arrayjkjp]; 

} 

J  -l*i; 

} 

for  (k-0;  k < 20;  ++k) 

{ 

array[k]p  + 1)  «  temp  array[k]; 

> 

} 


> 


/*- 
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/*  Load  KES  knowledge  base  and  remove  Infeas  */ 

/. - - - •/ 

int  exp_eetup(array, limit,  pl_opt) 

lntarray[20] [256], limit,  pi  opt; 

{ 

Int  newjlmtt; 
char  *pm_buf; 
char  pnl_in[2] ; 

char  -result; 

KESatrtype  Removalvector; 
static  char  ok2_lst[]  -  {V,'y,,‘q,,'h7\0'}; 


KES_run_actton«0; 


expert: 

KES_obtain(Removal_vector); 

result  »  KES_g_value_str(Removal_vector); 

newHmit  «  R*mov_v*c(*rr*y,r**utt,li(nit,p  1_opt); 

wn_dr(w3); 

wn  _puts(w3, 1,5, 'Outcome  Removed"); 
wo_putt(w3,2,5,re*ult) ; 

wn_dr(w4), 

•prtntf (pfn  buf ,‘%d‘,n*w  limit) ; 

wn  _puts(w4, 1 ,5,pm_buf); 

wnj>uts(w4, 1,1 5,  "Remaining  Outcome*  in  set"); 

wn_puts(w4,2,5,"Remove  another  outooma-Y,  Continue-cr”); 

If  (silent  Jig  -  -  FALSE) 

{ 

and  confirm  0; 

> 

wnk>cate(w4,2,45); 
wn_gets(w4,pnl_ln,6,ok2_lst); 
twitch  (*pnl_in) 

{~ 

caaa  V: 

KE8_erase(  KESnullatrc); 

free  (result);  /*  KES_g_value_atr  malloc’s  the  space  so  free  it  */ 

limit  »  newjimit; 
goto  expert; 
break; 


case  y; 

KES_erase(  KES  null  atr  c); 

free(reault);  /•  KESgvaluestr  malloc’s  the  space  so  free  it  */ 

limit  »  newjimit; 
goto  expert; 
break; 


case  ’\0’: 

KES_erase(  KES_null_atr_c); 

free(result);  /*  KES_g_value_str  malloc’s  the  space  so  free  it  */ 

break; 


default: 

KES_erase(  KES_null_atr_c); 

free(result);  /*  KES_g_value_str  malloc’s  the  space  so  free  it  */ 

break; 

} 

retum(newjimit); 

> 

r - 7 

/*  Load  KES  knowledge  base  and  rank  outcome  */ 

/* - 7 

int  rankout  (array,  limit,  plopt) 

Int  array [20] [256], limit,  p1_opt; 


a 


lot  nawHmlt; 
char  *rank[4]; 
char  pnl_ln{2] ; 

KESatrJypa  Rank1_vactor.Rank2_vactor,Rank3  vactor; 

•tatkj  char  ok3_tet[]  -  {T ,y .'q-.h' ,V) ; 


Ranklvactor 
Rank2_vactor 
Rank3  vactor 


•xpartl: 


■  KESgatrfrankl") 
KES_g_atrfrank2") 
KES_g_atrfrank3‘) 


wn_dr(w4); 


KESobtain  (Rank  t  _vactor) ; 

rank(1]  -  KES_g_valua_str(Rank1_vactor); 

KES_araaa(  KES_null_atr  c); 

KESobtain  (Rank2_vactor) ; 

rank [2]  -  KES_g_valua_«tr(Rank2_vactor); 

KES_araaa(  KES_null_atr_c); 

KES_obtain(Rank3_vactor); 

rank [3]  «  KES_g_vaJua_etr(Rank3_vactor); 

KES_era*e(  KESjtullatrc); 

Sort_o«it  (array, rank, limit, p  1  _opt); 
wn_dr(w3); 

wn_puta(w3, 1,5, "Rank  Kay  lor  aorting"); 
wn_puts(w3,2,5,rank[l  ]); 
wn_puta(w3,3,5,rank[2]); 
wn_puts(w3,4,5,rank[3]); 


wn_pot*(w4, 1,5, ‘Rank  again-Y,  Continue-cr"); 
If  (tifant  fig  -  «  FALSE) 

"  { 

•ndoonflrmO; 

} 

wnlocate  (w4 ,2,45) ; 
wn_gats(w4,pnl Jn,6,ok3  let); 
twitch  (*pnl  ln) 

{' 


KES_arata(  KES_null_atr  c); 


fraa(rank[1]) 
lraa(rank(2]): 
fraa(rank[3]) 
goto  axpartl 
break; 


/*  KES_g_valua_ttr  malloc's  the  space  so  tree  it  */ 


case  ’y’: 

KES_art8a(  KES_null_atr_c); 

fraa(rank[1]);  /»  KES_g_value_str  malloc's  the  space  so  free  it  */ 

free(rank[2]); 

lraa(rank(3]); 

goto  axpartl; 

braak; 


free(rank[1]) 
free(rank[2]) 
free  (rank  [3]) 
bfMk; 


/*  KES_g_value_str  malloc's  the  space  so  free  it  */ 


default: 


KES_eraee(  KESnullatrc); 
free(rank[2]); 


free(rank[3]) 

free(rank[1]) 

break; 


/•  KES_g_value_str  malloc's  the  space  so  free  it  */ 


return  (newjimit); 


/*  MAIN  Program  starts  here 

r - v 

main(argc.argv) 
intargc; 
char  *argv[]; 


static  int  Prefvec_1  [20]  [256] ; 
static  int  Prefvec_2[20]  [256] ; 

static  int  same_vec[256]; 
static  int  row ; 
int  limit,  I.  ],  k,  pwl; 

int  choose  ,  pi  opt,  p2_opt,  numjjpt,  space  ; 

int  quit,  horz  pos,  vertjxjs,  lenvect,  column,  Ien_vec2 ; 
int  ‘array ; 

char  ansi  [256],  ans2[256],  Ans[256] ; 
char  pt_ans1[2],  pt_ans2[2] ; 
char  player  1  [20],  player2[20] ; 
char  option  [20],  testflag[8] ; 
char  pm_buf[5],  dec_vec[5],  pnl_ln[2] ; 

static  char  diagftgl]  »  {'/diag"}; 
static  char  okljstf]  -  {•h\’\0'}; 
char  ‘KB  RLE  «  {■conflict.pkb''}; 


r - v 

/*  Test  the  BIOS  for  screen  update  method  */ 

/* - 7 

If  (_osmajor  <  3) 
wndmaflg  «  FALSE ; 

/* - 7 

/*  Test  the  Command  Line  for  switches  */ 

/* - 7 

If  (argc I-  1) 

{ 

for  (i»1;  i<  -argc;  ♦  +i) 

{ 

If  (strcmp(argv(i], diag  fig)  -  «  0) 

{ 

diagnostic  0; 


H  («trcmp(argvp],70  »  *  0) 

{ 

faat_flag«TRUE; 

> 

If  (*tfcmp(argv[i],7*-)  »  «  0) 

{ 

8llent_flg»TRUE; 

} 

If  (atrcfnp(argv[i]l7rank")  «  «  0) 

{ 

aort_flg=TRUE; 

> 

if  (strcfnp(afgv[i],7«")  -  -  0) 

{ 

exp_flg*TRUE; 

> 

If  (atrcmp(argv[i],7video‘)  «  »  0) 

{ 

wn_dmaflg  «  FALSE; 

> 

If  («trcnnp(argv[i],7kb')  -  -  0) 

{ 

axp_flg«TRUE; 

♦  +i; 

aprintf(KB  FILE,’%a-,argv[i]); 

} 


I*  Sava  entry  acreen  ao  we  can  return  It  whan  dona  */ 

/• - •/ 

wO  -  wn  aava (0,0,0,78, 23 ); 

If  (!wO)  axtt  (0); 

/* - 7 

/*  Checkered  background  pattern  •/ 

/• - 7 

1or(l«0;  l<25;  I++) 

{ 

vlocate  (0,1,0); 

v_wca(0,  OxbO,  Wht  BIk,  80); 

> 

y_hldacO;  /*  turn  off  the  curaor  */ 

/* - 7 

/*  Open  window  FOR  LOGO  7 

/*• - 7 

If  (faatflag  -  -  FALSE) 

diaplogoO; 

/* - 7 

/*  Gat  the  Inatructiona  7 

/. - v 

If  (faat  flag  -  -  FALSE) 

InatructQ; 


r - v 

/*  Setup  the  main  work  screen  */ 

/*• - */ 

newgame: 

dispworkO; 

/*— - V 

/*  Sat  up  Players  •/ 

/* - 7 

wn _puts(w4,2,5,'What  Is  the  nama  of  the  first  player  ?"); 

H  (silentfig  -  »  FALSE) 

{ 

snd_confirmO; 

} 

wnsync  (w2,TRUE) ; 
wn  locate  (w2, 2,0); 
wn_gets(w2,  playerl,  4,  0); 
wn_putsa(w2, 2, 0,  playerl,  RedYel); 

for(p1_opt«0 ;  p1_opt<5  ;  +  +  p1_opt) 

{ 

wn_clr(w4); 

wn_puts(w4,2,5,*Enter  option-  short  phrasa,  please*); 

If  (silent  fig  -  -  FALSE) 

{ 

sndconfirmO; 

> 

wn_locate(w2,  pl  opt  +  4,3); 
wn_gets(w2,  option,  4,0); 
if  (‘option  -  -  NULL) 
break  ; 

wn_putsa(w2,  p1_opt  +  4, 3,  option,  BluWht); 

} 

wn_dr(w4); 

wn_puts(w4, 2,5, "What  is  the  name  of  the  second  player  ?*); 
If  (silentjlg  -  -  FALSE) 

{ 

sndconfirmO; 

} 

wnjocate(w2,9,0); 

wn_gets(w2,player2,4,0); 

wn  putsa (w2,9,0 .player 2, Red _Yel ) ; 

for(p2_opt«0  ;  p2_opt  <  4  ;  +  +  p2_opt) 

< 

wn_dr(w4); 

wn_puts(w4,2,5,"Enter  option-  short  phrase,  please"); 

If  (silentjlg  -  -  FALSE) 

{ 

snd_oonfirmO; 

} 

wn_k>cate(w2,p2_opt  +  11,3); 
wn_gets(w2, option, 4,0); 

If  (‘option  -  -  NULL) 
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break ; 

wn_putsa(w2,p2  opt+1 1,3, option, Blu  Wht); 

> 

wn_sync(w2,  FALSE); 
v_hidecO; 

/* - 1 - 7 

/*  Generate  allVectors  */ 

/*• - 7 

out_come: 

num_opt  -  p1_opt  +  p2_opt; 

♦or  (I” 0, limit ■ 1 ;  i < num_opt;  +  +  i) 

{ 

limit  *  limit  *  2; 

> 

wn_dr(w3); 

wn_dr(w4); 

sprintf(prn_buf,’%d’, limit); 
wn_put8(w4,2,5,prn_buf); 
wn_puts(w4, 2, 10, ’possible  combinations  ’); 
Generate  (p1_opt,p2_opt,limit,Prefvec_1); 

/* - 7 

/*  Load  a  knowledge  base  into  KES  7 

r - 7 

if  (expflg  -  -  TRUE) 

{ 

KES_ld_kb(KB_FILE.  MEM  SIZE ); 
limit  -  exp_setup(Prefvec_1, limit, pi  opt); 

} 

/* - 7 

/*  Redisplay  outcomes  after  removals  */ 

/* - 7 

if  (exp  flg  -  -  TRUE) 

{ 

New_out(p1_opt,p2  opt, limit, Prefvec_1); 

> 

wn_puta(w3, 0,20, "Outcomes  Remaining’); 
wn_putsa(w3, 0,50, playerl, Red  Yel); 

/*• - : - 7 

/*  copy  prefvec  1  into  prefvec  2  */ 

r - 7 

for  (1=0;  i <256;  +  +i) 

{ 

for  (j=0;  j <20;  +  +j) 

{ 

Prefvec_2[j][i]  =  Prefvec_1[j][iJ; 

} 

} 

wn_clr(w4); 

wn_put8(w4,2,10,’CR,to  rank  player  1-  h  for  help  "); 
if  (silent  ffg  =  =  FALSE) 

snd_confirm(); 

> 


mm 


wnjocate  (w4,2,45) ; 
wn_gets  (w4,pnl  Jn  ,6, ok  1  Jst) ; 
if  (*pnl  in  »  =  ’h') 

goto  poppni; 

/* - 7 

/*  Rank  outcomes  after  removals  by  expert  */ 

/* - 7 

If  (exp  fig  =  =  TRUE) 

{ 

rank  out(Prefvec_1,limit,p1_opt); 

} 

/*■ - 7 

/*  Redisplay  outcomes  after  removals  */ 

/* - 7 

if  (expflg  =  =  TRUE) 

{ 

alter_vec(Prefvec_1 , limit, playerl  Pp1_opt,p2_opt); 

} 

/*• - 7 

/*  Run  stability  on  Prefvec  1  */ 

/* - -7 

if  (exp  fig  =  =  TRUE) 

{ 

for  (i=0;  i<  limit;  +  +i) 

{ 

stable(p1_opt+1,num_opt,i,Prefvec_1); 

> 

wn_clr(w 4); 

wn  puts(w4,2,10,"CR,to  rank  player  2-  h  for  help  "); 
if  (silent Jig  =  =  FALSE) 

{ 

snd_confirm{); 

} 

wn_locate(w4,2,45); 

wn_gets(w4,pnlJn,6,ok1_lst); 

if  (*pnl_in  =  =  ’h’) 

goto  pop_pnl; 

> 

/* - 7 

/*  Flank  outcomes  after  removals  by  expert  */ 

r - 7 

if  (exp  flg  =  =  TRUE) 

{ 

rank_out(Prefvec_2, limit, p1_opt); 

> 

r - 7 

/*  Fledisplay  outcomes  after  removals  */ 

r - 7 

if  (exp  fig  =  =  TRUE) 

{ 

alter  _vec(Prefvec_2, limit, player2,p1_opt,p2_opt); 

> 

/* - 7 
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/*  Run  stability  on  Prefvec_2 

/*■ - 7 

If  (expjg  -  -  TRUE) 

{ 

for  (i — 0;  iclimit;  +  +i) 

{ 

stable(1  ,p1_opt,i,Prefvec_2); 

> 

wn_clr(w4); 

wn_puts(w4,2,10,'CR,to  solve-  h  for  help  "); 

if  (silentjg  =  =  FALSE) 

{ 


snd  confirm  0; 

> 

wn  Jocate  (w4,2,45) ; 
wngets (w4,pnl  in ,6, ok  1  1st) ; 

If  (*pnl_in  =  =  ’h’) 


> 


goto  pop_pnl; 


/* - 7 

/*  Skip  manual  ordering  if  expert  on  */ 

r - 7 

if  (exp Jig  =  -  TRUE) 

{ 


Ien_vec1  =  limit; 

Ien_vec2  =  limit; 

KES  free  kbO; 
goto  busy; 

} 

/. - 7 

/*  Start  the  ordering  of  decimal  vectors  for  player  1  */ 

/*■ - 7 

wn_clr(w4); 

wn_puts(w4,2,10,"CR,to  continue-  h  for  help  “); 
if  (silent  fig  =  =  FALSE) 

{ 

snd_confirm(); 

} 

wnJocate(w4,2,45); 
wn_get8(w4,pnl  Jn,6,ok1  1st); 

if  (*pnljn  =  *  ’h’) 

goto  pop_pnl; 

playl  Jn: 

horz_po8  =  0; 

num_opt  =  p1_opt  +  p2_opt; 
quit  =  FALSE; 

for  (Ien_vec1  »0;  Ien_vec1  <  256;  +  +len_vecl) 

{ 

horz_po8  -  horz  pos  %  45; 
if  (horz_pos  «  ■  0) 

{ 

wn_clr(w3); 

wn_puts(w3, 0,20,  "Preference  Vectors"); 
wn_putsa(w3,0,50,player1  ,Red_Yel); 


wn_dr(w4); 

wn_puts(w4,2,5,’Enter  VECTOR  or  +  for  binary- "); 

If  (silentflg  »  -  FALSE) 

{ 

sndconfirmO; 

> 

wn  locate  (w4, 2,45) ; 
wn_get3(w4,dec_vec,2,0); 

switch  (*dec_vac ) 

{  ~ 

case  NULL: 

quit  -  TRUE; 
break; 

case 

goto  want_out; 
break; 

case 

Gon2dec(num_apt,p  1  opt,horz_pos,  len_vec1,Prefvec_t); 
sprintf(dec_vec,  ”%d",  Prefvec_1(0](len_vec1]); 

wn_putsa(w3,2,horz_pos,dec__vec,Blu  Wht); 
stable  (p  1  opt  + 1  ,num_opt,len_vec1 ,  Prefvecl ) ; 
break; 

default: 

con2bin(dec_vec,num_opt,len_vec1,Prefvec_1); 
wn_putsa(w3,2,horz_pos,dec  vec.Blu  Wht); 
stable  (p1_opt+  1,num_opt,len_vec1  ,Prefvec_1); 

for  (i= 1,  spacers ;  l<  «num  opt ;  ++i) 

{ 

H  (I  >  pl  opt) 
space  -  10  -  pi  opt ; 

sprintf(dec_vec,  "%d\  Prefvec_l[i][len_vec1]); 
wn_puts(w3,l  +  space, horzpos.decvec); 

} 

break; 

> 

if  (quit  -  -  TRUE) 
break; 

horz  poa  -  horz  pos  +■  3; 


wn_clr(w4); 

wn_puts(w4.2,10,‘CR,to  player  2-  h  for  help '); 

If  (silentflg  -  -  FALSE) 

{ 

snd_confirmO; 

> 

wn_locatefw4,2,45); 
wn_gets(w4,pnl_in,6,okl  1st); 

H  (*pnl  in  -  -  h  ) 

goto  poppnl; 

/* - -7 

/*  Start  the  ordering  of  decimal  vectors  for  player  2  */ 


/. - V 

play2_in: 

wn_dr(w3); 

wn_puta(w3, 0,20, ’PREFERENCE  VECTORS’); 
wn_putaa(w3,0,50,player2,Red_Yel); 
horz  po s  »  0; 
quit  -  FALSE; 

for  (I«n_vec2«0;  Ien_vec2  <  256;  +  +  Ien_vec2) 

{ 

horz_pos  «  hora_pos  %  45; 
if  (horzpos  =  =  0) 

’  { 

wn_clr(w3); 

wn_puts(w3, 0,20, "Preference  Vectors’); 
wn_putsa(w3, 0,50, player2, Red  Yel); 

> 

wn_clr(w4); 

wn_puts(w4,2,5,*Enter  VECTOR  or  +  for  binary’); 
if  (silentflg  =  «  FALSE) 

{ 

sndconfirmO; 

} 

wn  Jocate  (w4,2,45) ; 
wn_gets(w4,dec_vec,2,0); 
switch  (*dec_vec ) 

{ 

case  NULL: 

quit  »  TRUE; 
break; 

case 


goto  want_out; 
break; 

case 

con2dec(num_opt,p1_opt,horz_pos,  len_vec2,Prefvec_2); 
sprlntf(dec_vec,  “%d’t  Prefvec_2[0][len_vec2]); 

wn_putsa(w3,9,horz_pos,dec_vec,Blu_Wht); 
stable (p1_opt+ 1  ,num_opt,len  vec2,Prefvec_2); 
break; 

default: 

con2bin(dec_vec,num_opt,len_vec2,Prefvec_2); 
wn_putsa(w3,9,horz_pos,dec_vec,Blu_Wht); 
stable  (1  ,p  1  _opt,len_vec2,Prefvec_2); 

for  P  —  1  .space  =  3  ;  i  <  -  num_opt ;  +  + 1) 

{ 

If  0  >  pl_opt) 
space  *  10-p1_opt ; 

sprintf(dec_vec,  ‘%d’,  Prefvec_2[i])len_vec2]); 
wn_puts(w3,i + space, horz_pos,dec_vec); 


> 

If  (quit  =  =  TRUE) 
break; 
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horcjjo*  »  horz_pos  +  3; 


> 

wn_clr(w4); 

wn_puts(w4,2,10,"CR,for  Ul  s~  h  for  help  “); 
if  (silent_flg  -  -  FALSE) 

{ 

sndconfirmO; 

> 

wn_locate{w4,2,45); 

wn_gets(w4,pnl_ln,6,ok1_lst); 

if  (*pnl_in  -  «  ’h’) 

goto  pop_pnl; 

/*• - 7 

/*  Busy  message  to  user  */ 

/*■ - v 

busy: 

wn_clr(w3); 

wn_putsa(w3, 7,10, "BACK  IN  A  MOMENT, Red_Yet); 

If  (silent_flg  *  ■  FALSE) 

{ 

snderrorO: 

> 

/* - 7 

/*  Find  the  same  vector  in  2  */ 

/*■ - 7 

Find_8ame(Prefvec_1,Prefvec_2,8ame_vec,len  vecl.len  vec2); 

/* - : - : — 7 

/*  Solve  the  Ul’s  into  r.s.or  u  */ 

/- - 7 

solve(len_vec1  ,len_vec2,Prefvec_1  .Prefvec  2, ansi ,ans2); 

/*' - 1 - —7 

/*  Simultaneous  Sanction  Check  */ 

/*■ - 7 

slmul_sanct0en_vec1,len_vec2,ans1,ans2,8ame  vec, Prefvec  1,Prefvec_2); 

/*• - : - : - 7 

/*  Solve  r.s.u  into  equilibriums  */ 

r - 7 

equilibrium  (Ien_vec1,  ansi,  ans2,Ans,Prefvec_1,Prefvec_2,same_vec); 

/*• - 7 

/*  Final  Stability  table  •/ 

/* - 7 

fin_tableOen_vecl  ,len_vec2,ans1  ,ans2,Ans,Prefvec_l  ,Prefvec_2); 

/* - 7 

/*  Control  panel  operation  */ 

/* - 7 

cntr1_pnl: 

wn_clr(w4); 

wn_puts(w4,2, 1 0,'CR-QUIT  or  h-HELP’); 
wn_locate(w4,2,45); 
wn_gets(w4,pnl_in,6,ok  1  1st); 

pwl  «  0; 

poppnl: 

If  (*pnl_in  -  -  h' ) 
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{ 


pwl  -  popup(0,5,5,33,14,Yel_Grn,Grn_Wht,&poplnfo,TRUE) ; 
switch  (pwl) 

{ 

case  1: 

goto  playl  in; 
break; 

case  2: 

goto  play2_in; 
break; 

case  3: 

goto  new_game; 
break; 

case  4: 

user_helpO; 
goto  cntrt_pnl; 
break; 

case  5: 

diagnosticO; 
it  (user_clrflg  «  *  TRUE) 
disp_work(); 


goto  cntrl_pnl; 
break; 

case  6: 

ui_review(len_vec1  ,len_vec2,ans1  ,ans2,Ans,Prefvec_1  ,Prefv 

ec_2); 

goto  cntrlpnl; 
break; 

case  7: 

exp_flg  =  TRUE; 
goto  out  come; 
break; 

case  99: 

goto  cntrt_pnl; 
break; 

default: 


goto  want_out; 
break; 


want  out: 


} 


} 


wn_close(w4); 

wn_dose(w3); 

wn_dose(w2); 

wn_dose(w1); 

wn_restore(wO); 

if  (silent  flg  •  -  FALSE) 

'  { 

laffO; 


> 


/* - 7 

/•  This  is  the  last  statement  in  Main  and  will  automatically  terminate  */ 

- - - 
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}/*  *nd  */ 
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the  choice  of  tools  and  software.  Third,  the  prototype  was  built  using  two  parallel 
development  tracks.  Separate  design  components  were  completed  in  the 
conventional  C  language  program  and  in  the  expert  system  program.  When  fully 
tested  and  debugged,  the  two  programs  were  integrated  within  the  C  language 
program.  Proper  system  performance  was  evaluated  by  comparison  of  results 
using  a  varied  selection  of  classic  problems.  Finally,  the  results  of  the  research 
are  presented  with  recommendations  for  future  work. 
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